Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Luca Boccassi]

On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann <anbe at debian.org>
wrote:
> Package: systemd
> Version: 252.6-1
> Severity: serious
> User: debian-qa at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230529/39a9d705/attachment-0001.sig>