Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

[Luca Boccassi]

On Tue, 30 May 2023 at 14:09, Helmut Grohne <helmut at subdivi.de> wrote:
>
> Hi Luca,
>
> On Tue, May 30, 2023 at 11:23:07AM +0100, Luca Boccassi wrote:
> > > > - unmerged-usr paths are no longer supported
> > >
> > > Then you argue that this bug would affect only unmerged systems, while
> > > it actually is in reverse. Unmerged systems are unaffected by this bug
> > > class. The deletion that Andreas describes can only happen due to the
> > > aliasing introduced by merging. This bug class only affects merged
> > > systems.
> >
> > No, this bug report only affects unmerged systems and has no effect on
> > merged ones, as the actual bug after the analysis and discussion is
> > that some packages since Bullseye install modules-load.d/ files in the
> > wrong directory, that nothing actually reads (since Bullseye!),
> > effectively making them useless, but nobody ever noticed, and I can
> > only speculate that this could be due to the fact that the vast
> > majority of systems have been merged and thus there's no difference
> > (alternatively it could be that such packages have extremely low
> > popcon, I have not checked). If these packages were used on unmerged
> > system, these bugs would be very real - the functionality they provide
> > would be broken.
>
> Given that we are saying exactly the opposite of each other, it seems
> likely that we are talking about different things (thanks to that kind
> soul pointing it out to me).
>
> As I read your reply, it seems to me that you see the bug in
> multipath-tools and other packages that ship files in
> /lib/modules-load.d as opposed to /usr/lib/modules-load.d. Assuming
> that's your view, what you write very much makes sense - including the
> assertion that it only affects unmerged systems. Do you confirm? If you
> confirm, I'd see what you see as the bug we are talking about as not an
> issue in systemd at all, but as multiple issues in other packages (such
> as multipath-tools) that fail at integrating properly with systemd (when
> unmerged, which is unsupported, so not worth fixing in bookworm). Given
> that the bug at hand is filed against systemd (rather than
> multipath-tools), it did not occur to me earlier that you were having
> this problem in mind.

Yes, that's exactly right - this behaviour was changed a long time ago
(for Bullseye) as mentioned earlier in the thread:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282

so it could of course be changed back so that files in /lib are picked
up instead - but as mentioned, I don't think it's worth it, especially
not this late. Packages installed in unmerged Bullseye shipping files
in /lib/modules-load.d have been buggy ever since, and on a merged
system it's just a cosmetic issue. This is (was) a severity serious
bug against src:systemd and that's how I approached it.

> As I understand what Andreas wrote (maybe he can confirm), the problem
> he sees is that /usr/lib/modules-load.d (the directory) disappears when
> removing other packages such as multipath-tools. So it's very much not
> about whether systemd deals with the dropins placed by multipath-tools.
> It's about removal of a package having unintended side-effects (removing
> a directory still owned by systemd). And this very problem, can only be
> experienced on merged /usr. The absence of a directory may not seem like
> a big deal to you and none of us seems convinced that it has a
> practically relevant impact on using systemd, but it very much has an
> impact on piuparts and testing migration and that - to me - is what this
> bug report has been about.
>
> Does that make more sense to you now?

Yes, that makes sense. However I don't think it needs to be a release
blocker? AFAIK there are no load-modules.d/ migrations left to do for
bookworm, and we can make sure piuparts is happy in trixie. Do you see
any reason why this should be a release blocker?

Kind regards,
Luca Boccassi