On Tue, 30 May 2023 at 10:53, Helmut Grohne <hel...@subdivi.de> wrote: > > Context for d-devel: > > Andreas Beckmann noticed that systemd ships an empty directory > /usr/lib/modules-load.d. When removing a package that ships a file in > /lib/modules-load.d (such as multipath-tools), dpkg may in some > circumstanced delete the empty directory owned by systemd. > > On Mon, May 29, 2023 at 07:24:09PM +0100, Luca Boccassi wrote: > > Given what was discussed: > > I think the conclusion is drawn too quickly here. > > > - bookworm is in hard freeze > > - there is no functional impact > > In effect, this bug report is an instance of a bug class. I am in the > process of quantifying its effects, but I do not have useful numbers at > this time. As an initial gauge, I think it is about 2000 binary packages > that ship empty directories (which does not imply them to be affected, > rather this is to be seen as a grossly imprecise upper bound).
Not quite - this bug report is filed against src:systemd, and it's about precisely one thing - the modules-load.d/ directory, and the reply you are quoting is talking explicitly about that. > > - 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. Now you want to talk about a different issue - that is fine of course, but it's not what I was talking about. > In my earlier reply, I also asked Andreas for a practical impact on > systemd users and suggested lowering the severity of this instance. > However, there is more to consider. This poses a problem to piuparts and > thus testing migration. Making piuparts happy is a use case of its own. > When a mitigation for non-essential adduser broke piuparts (again, I'm > sorry about that), the release team decided that piuparts is an > important piece of the release process and therefore the change was to > be reverted. As a result, apt now depends on adduser in bookworm again. > To be clear, I fully support the decision that has been made here and > thank the release team for dealing with resulting issues (e.g. delayed > migration of other packages). Since the problem we are discussing here > is quite similar, I argue that this problem class also should be > considered release critical in general, because it may impact testing > migration. That being said, IANARM and I therefore leave that judgement > to others. /lib/modules-load.d/ being ignored (and thus packages shipping files there being buggy) has been the case since Bullseye, as already mentioned. If it was not release critical for Bullseye, why should it be for Bookworm? > > - as soon as trixie opens for business we might just canonicalize > > everything (assuming all the ducks will be in a row) > > You make this look like a simple way forward. The qualifications in that sentence were included to do precisely the opposite. Kind regards, Luca Boccassi
