Splitting udev-udeb out of src:systemd

[Luca Boccassi]

Hi Cyril,

I plan to split out udev-udeb and libudev1-udeb from the current
src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

This should greatly reduce your workload as src:systemd uploads will
no longer be in your way and require actions/reviews, and I do not
plan to update src:systemd-udeb more than once per major upstream
release in unstable, and never in stable-p-u. It will also allow me to
apply several improvements to src:systemd that are currently blocked
by the fact that udebs are built from it. The udeb source package will
be much smaller and leaner, with drastically cut build deps and so on.
So it should be a win/win all around.

Are there any particular precautions I should take? It will require a
trip through NEW, so for a time the udeb might disappear from unstable
until it is processed, but hopefully won't be too long. I think
there's somewhere a list of source packages building udebs, that will
need to be updated. Anything else?

Thanks!

[Cyril Brulebois]

Hi Luca,

Post by Luca Boccassi
I plan to split out udev-udeb and libudev1-udeb from the current
src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).
This should greatly reduce your workload as src:systemd uploads will
no longer be in your way and require actions/reviews, and I do not
plan to update src:systemd-udeb more than once per major upstream
release in unstable, and never in stable-p-u. It will also allow me to
apply several improvements to src:systemd that are currently blocked
by the fact that udebs are built from it. The udeb source package will
be much smaller and leaner, with drastically cut build deps and so on.
So it should be a win/win all around.

Indeed, that looks like a very solid plan, thanks! Especially if the
split package gets sync'd from time to time (as opposed to be forgotten
about forever — which could work for some other components, but not
quite for something as dynamic and tied to the Linux kernel as udev).

Post by Luca Boccassi
Are there any particular precautions I should take? It will require a
trip through NEW, so for a time the udeb might disappear from unstable
until it is processed, but hopefully won't be too long. I think
there's somewhere a list of source packages building udebs, that will
need to be updated. Anything else?

I think this heads-up is sufficient. Depending on the versioning and
timing of the two source packages, and when you drop the udeb, there
might be a smoothless transition (~ “live takeover”), or a going-away-
then-back-again, and we can live with daily builds being broken for a
few days anyway. There's no imminent release either, so all good.

The list of udeb-producing packages is monitored and I'll update it
indeed. I might have to tweak some tooling to get meaningful diffs to
build the next release announcement, but that's really just for me.

I don't think there's anything else that should care about such details
(the tricky part I could think of is the Built-Using generation and even
that doesn't seem to list either systemd or udev so everything should be
fine already).

Feel free to go ahead whenever you are ready. I'll probably see the
package getting out of NEW on my own, but feel free to follow up once
it's ACCEPTED if you remember/can spare a minute, so that others know
the “red moment due to the systemd split” moment (if any) is over.


Cheers,

[Luca Boccassi]

Post by Cyril Brulebois
Hi Luca,

Post by Luca Boccassi
I plan to split out udev-udeb and libudev1-udeb from the current
src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).
This should greatly reduce your workload as src:systemd uploads will
no longer be in your way and require actions/reviews, and I do not
plan to update src:systemd-udeb more than once per major upstream
release in unstable, and never in stable-p-u. It will also allow me to
apply several improvements to src:systemd that are currently blocked
by the fact that udebs are built from it. The udeb source package will
be much smaller and leaner, with drastically cut build deps and so on.
So it should be a win/win all around.

Indeed, that looks like a very solid plan, thanks! Especially if the
split package gets sync'd from time to time (as opposed to be forgotten
about forever — which could work for some other components, but not
quite for something as dynamic and tied to the Linux kernel as udev).

Post by Luca Boccassi
Are there any particular precautions I should take? It will require a
trip through NEW, so for a time the udeb might disappear from unstable
until it is processed, but hopefully won't be too long. I think
there's somewhere a list of source packages building udebs, that will
need to be updated. Anything else?

I think this heads-up is sufficient. Depending on the versioning and
timing of the two source packages, and when you drop the udeb, there
might be a smoothless transition (~ “live takeover”), or a going-away-
then-back-again, and we can live with daily builds being broken for a
few days anyway. There's no imminent release either, so all good.
The list of udeb-producing packages is monitored and I'll update it
indeed. I might have to tweak some tooling to get meaningful diffs to
build the next release announcement, but that's really just for me.
I don't think there's anything else that should care about such details
(the tricky part I could think of is the Built-Using generation and even
that doesn't seem to list either systemd or udev so everything should be
fine already).
Feel free to go ahead whenever you are ready. I'll probably see the
package getting out of NEW on my own, but feel free to follow up once
it's ACCEPTED if you remember/can spare a minute, so that others know
the “red moment due to the systemd split” moment (if any) is over.

New source package has been accepted and both uploads are now in unstable