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
