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

[Helmut Grohne]

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.

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?

Helmut