On Tue, 30 May 2023 at 14:09, Helmut Grohne <hel...@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
