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

[Cyril Brulebois]

Hi,

Post by Luca Boccassi
New source package has been accepted and both uploads are now in unstable

Thanks for the heads-up.

I'm seeing a lot of things that are different, for what should be just a
new revision/move. Are those expected? (diff generated on amd64, diffing
udev-udeb between testing and unstable)

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id

Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link
-rw-r--r-- root/root /usr/lib/systemd/network/99-default.link

More importantly, udev-udeb isn't installable, as it depends on libkmod2
(not its udeb counterpart) — and that's the only change in Depends.

This seems to be picked up via:

debian/udev-udeb.substvars:dlopen:Recommends=libkmod2

which is a variable that wasn't being used for udev-udeb before the
split but is now:

Package: udev-udeb
Build-Profiles: <!noudeb>
Package-Type: udeb
-Section: debian-installer
Architecture: linux-any
Depends: ${shlibs:Depends},
${misc:Depends},
- util-linux-udeb
+ ${dlopen:Recommends},
+ ${dlopen:Suggests},
+ util-linux-udeb,

Package: libudev1-udeb
Build-Profiles: <!noudeb>
Package-Type: udeb
-Section: debian-installer
Architecture: linux-any
Depends: ${shlibs:Depends},
- ${misc:Depends}
+ ${misc:Depends},
+ ${dlopen:Recommends},
+ ${dlopen:Suggests},


Cheers,

[Luca Boccassi]

Post by Cyril Brulebois
Hi,

Post by Luca Boccassi
New source package has been accepted and both uploads are now in unstable

Thanks for the heads-up.
I'm seeing a lot of things that are different, for what should be just a
new revision/move. Are those expected? (diff generated on amd64, diffing
udev-udeb between testing and unstable)
Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id
Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link
-rw-r--r-- root/root /usr/lib/systemd/network/99-default.link

The old udev-udeb.install was severely bitrotting, as it seems it was
copied at some point from the main one, but then largely left as-is.
Normally dh-missing would warn about these things, but of course the
main udev package is picking all new files up, so there was no
warning.
I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. It seems correct that all rules files (and
all helper tools that are called in them) are shipped, rather than an
arbitrary subset. Those are all rules and tools that were added since
the last time udev-udeb.install was changed.
And it seems to me the network files serve no purpose, as there's no
networkd udeb, no?

Post by Cyril Brulebois
More importantly, udev-udeb isn't installable, as it depends on libkmod2
(not its udeb counterpart) — and that's the only change in Depends.
debian/udev-udeb.substvars:dlopen:Recommends=libkmod2

Whops, good catch - I had forgotten that addon cannot deal with udebs.
Removed and added libkmod2 manually, on its way to unstable now.

[Cyril Brulebois]

Post by Luca Boccassi
The old udev-udeb.install was severely bitrotting, as it seems it was
copied at some point from the main one, but then largely left as-is.
Normally dh-missing would warn about these things, but of course the
main udev package is picking all new files up, so there was no
warning.
I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. [
]

I wasn't meaning to sound like I'm challenging or anything, I just
debdiff'd old and new udebs, saw a lot of changes (in addition to the
extra dependency), that's why I asked.

Thanks for the confirmation/background.

Post by Luca Boccassi
Whops, good catch - I had forgotten that addon cannot deal with udebs.
Removed and added libkmod2 manually, on its way to unstable now.

Things are looking good again on the (un)installability side, thanks!


Cheers,

[Luca Boccassi]

Post by Cyril Brulebois

Post by Luca Boccassi
The old udev-udeb.install was severely bitrotting, as it seems it was
copied at some point from the main one, but then largely left as-is.
Normally dh-missing would warn about these things, but of course the
main udev package is picking all new files up, so there was no
warning.
I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. […]

I wasn't meaning to sound like I'm challenging or anything, I just
debdiff'd old and new udebs, saw a lot of changes (in addition to the
extra dependency), that's why I asked.
Thanks for the confirmation/background.

It didn't sound like that at all, no worries. If you see any problems
in the installer due to the lack of those network files, or the
presence of the rules files, let me know and I'll change it.

[Pascal Hambourg]

Post by Luca Boccassi

Post by Cyril Brulebois
I'm seeing a lot of things that are different, for what should be just a
new revision/move. Are those expected? (diff generated on amd64, diffing
udev-udeb between testing and unstable)
Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id
Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link
-rw-r--r-- root/root /usr/lib/systemd/network/99-default.link

(...)

Post by Luca Boccassi
I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. It seems correct that all rules files (and
all helper tools that are called in them) are shipped, rather than an
arbitrary subset. Those are all rules and tools that were added since
the last time udev-udeb.install was changed.

Does the installer really need rules for joysticks, cameras, v4l... ?
The new package installed size grows by 500kB (mostly due to additional
helper tools), which can be significant on low memory systems.

Post by Luca Boccassi
And it seems to me the network files serve no purpose, as there's no
networkd udeb, no?

I suspect that bug #1093907 ("predictable" name is not enforced) is
caused by the removal of these files.

[Luca Boccassi]

Post by Pascal Hambourg

Post by Luca Boccassi

Post by Cyril Brulebois
I'm seeing a lot of things that are different, for what should be just a
new revision/move. Are those expected? (diff generated on amd64, diffing
udev-udeb between testing and unstable)
Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id
Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link
-rw-r--r-- root/root /usr/lib/systemd/network/99-default.link

(...)

Post by Luca Boccassi
I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. It seems correct that all rules files (and
all helper tools that are called in them) are shipped, rather than an
arbitrary subset. Those are all rules and tools that were added since
the last time udev-udeb.install was changed.

Does the installer really need rules for joysticks, cameras, v4l... ?
The new package installed size grows by 500kB (mostly due to additional
helper tools), which can be significant on low memory systems.

Most of these seem to be useful, yes - storage, network, input
devices, output devices. I don't think it's worth excluding a couple
of small rules files, unless they actively cause trouble.

Post by Pascal Hambourg

Post by Luca Boccassi
And it seems to me the network files serve no purpose, as there's no
networkd udeb, no?

I suspect that bug #1093907 ("predictable" name is not enforced) is
caused by the removal of these files.

Strange, I guess these are used in some form then. I'll upload shortly
with these added back, thanks for the report.

[Cyril Brulebois]

Hi,

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).

The current set of packages doesn't work as the shlibs now only
references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.

(I'll file the mdadm bug report later on, I'm on my way out.)


Cheers,

[Luca Boccassi]

Post by Cyril Brulebois
Hi,

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).

The current set of packages doesn't work as the shlibs now only
references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.
(I'll file the mdadm bug report later on, I'm on my way out.)

libudev 1 libudev1 (>= 257.2)
udeb: libudev 1 libudev1-udeb (>= 257.2)
became
libudev 1 libudev1 (>= 257.2)
I'll do a few experiments and upload a fix as soon as I have it

Ok I have a fix that results in:

Package: mdadm-udeb
Source: mdadm
Version: 4.4-2
Architecture: amd64
Maintainer: Daniel Baumann <***@progress-linux.org>
Installed-Size: 1040
Depends: libc6-udeb (>= 2.40), libudev1-udeb (>= 247)

Which looks correct to me, so I'll upload that. mdadm will require a
rebuild afterwards. Thanks for finding this!

[Luca Boccassi]

Post by Luca Boccassi

Post by Cyril Brulebois
Hi,

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).

The current set of packages doesn't work as the shlibs now only
references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.
(I'll file the mdadm bug report later on, I'm on my way out.)

libudev 1 libudev1 (>= 257.2)
udeb: libudev 1 libudev1-udeb (>= 257.2)
became
libudev 1 libudev1 (>= 257.2)
I'll do a few experiments and upload a fix as soon as I have it

Package: mdadm-udeb
Source: mdadm
Version: 4.4-2
Architecture: amd64
Installed-Size: 1040
Depends: libc6-udeb (>= 2.40), libudev1-udeb (>= 247)
Which looks correct to me, so I'll upload that. mdadm will require a
rebuild afterwards. Thanks for finding this!

The fix is in unstable for all release arches, and I've re-tested the
mdadm build and the generated dependencies look correct, so mdadm can
be rebuilt now and it should work again. Please let me know if more
such issues appear.