On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann <a...@debian.org> wrote: > Package: systemd > Version: 252.6-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships an empty > directory (/usr/lib/modules-load.d/) which disappears after installation > and removal of another package (e.g. multipath-tools) in a merged- /usr > setup. This is not a bug in the other package, but an effect of our > merged-/usr implementation. > > Side question first: does systemd evaluate both > /usr/lib/modules-load.d/* and /lib/modules-load.d/* ? > Otherwise all packages shipping something in /lib/modules-load.d/ are > broken on unmerged-/usr because their config snippets are not being > taken into account.
The correct path since bullseye was /usr/lib/modules-load.d, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282 Anyway, we don't really care about what happens on unmerged installations, as they are no longer supported since Bookworm. > This is happening to trigger the bug: > > systemd ships /usr/lib/modules-load.d/ (empty directory) > multipath-tools ships /lib/modules-load.d/multipath.conf > dpkg doesn't know that /lib/modules-load.d/ and /usr/lib/modules- load.d/ > are the same, and therefore removal of multipath-tools causes removal of > * /lib/modules-load.d/multipath.conf (OK) > * /lib/modules-load.d/ (if it was the last owner of that directory), while > it effectively is /usr/lib/modules-load.d/ getting removed > > When adding a placeholder file, it needs to be something that is ignored > by the processing of the .d directory (the pattern could be *.conf, but I > might be mistaken here). > > An alternative to shipping a placeholder file could be shipping > /lib/modules-load.d/ as additional empty directory, but I don't know > whether this would be allowed w.r.t. merged-/usr. > > > From the attached log (scroll to the bottom...): > > 0m39.2s ERROR: FAIL: After purging files have disappeared: > /usr/lib/modules-load.d/ owned by: systemd > > > This is not caught by default piuparts tests as there is no test with > systemd explicitly installed. > > I could not reproduce this issue in bullseye (and haven't tried to > reproduce it in earlier releases). Wouldn't the correct workaround be to list /usr/lib/modules-load.d in systemd.dirs so that dpkg leaves it alone? Seems way too late for Bookworm though? -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
