Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
Hi, I fear we are not done with empty directory loss yet. This is a technical update for future reference. On Wed, May 31, 2023 at 11:59:58AM +0200, Helmut Grohne wrote: > On Tue, May 30, 2023 at 11:53:00AM +0200, Helmut Grohne wrote: > > 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). > > I did some more analysis work here and have to admit that I know my data > model has a weakness that may result in false negatives. I'd have to do > a complete reimport of packages and eventually will, so for now I'm > dealing with incomplete data here. I note that content indices do not > cover empty directories, so you really have to download loads of .debs > to find these. We're much further in understanding the problem now. > Anyway, to gauge the problem, we're effectively looking for a > combination of packages A and B such that: > > * A ships an empty directory. > * That empty directory is a path affected by aliasing (either in /usr >or /). > * B also ships that directory (e.g. non-empty) in the "other" >representation of that path. This earlier representation is incomplete. Moving a file from / to /usr (which currently is prohibited by the moratorium) as part of a simple package upgrade also triggers the loss behaviour. In any case, https://subdivi.de/~helmut/dumat.yaml now reports the affected instances (both when multiple packages are involved and upgrade scenarios) and it's not that many. > So yeah, this bug class is clearly not one to panic about. As we move > files from / to /usr, I expect this bug class to gain more occurences. I > am not aware of a generic solution and it seems diversions won't cut it. > If you can propose any generic workaround or recipe for this situation, > I'm all ears. The placeholder file sounds ugly, but might work. We've progressed somewhat since. At this time, my favourite mitigation is deleting affected directories and I've sent a number of patches for applicable situations. Unfortunately, some empty directories exist with reason and we need another mitigation for them. The options seem to be as follows: # M9 While dpkg does not allow diverting a directory, you can trick it into doing that by temporarily moving the directory out of the way. So diversions are an option here though they're really ugly. # M17 A way to not loose these directories is to keep them in both aliased and canonical location. While this works fairly reliably (until we attempt to remove the aliased location), it is incompatible with other mitigations such as shipping the aliasing symlinks in a package (M11). # M20 We can also accept the temporary loss of these directories and restore them using maintainer scripts. In upgrade scenarios, this is trivial as the postinst script runs after the loss event. In the package removal scenario, the package being removed can activate an interest-noawait trigger to restore the directory. I've implemented and attached a prototype for this approach. # M21 The obvious way to avoid loss of empty directories is to make them non-empty. Adding a placeholder file is sufficient here. All of these mitigations can be selected per-occasion (though selecting M17 once precludes a number of other ones). I don't think there is a clear winner here. We can leave the choice of mitigation to the affected maintainers. Rough outline on a per-package basis: * cockpit-tests: deleted #1043322 * firmware-b43-installer: /lib/firmware/b43 triggerless M20 * firmware-b43legacy-installer: /lib/firmware/b43legacy triggerless M20 * fwupd: delete #1041752 * gretl: deleted #1041835 * lib32lsan0 : deleted #1042482 * libjte-dev: deleted #1041753 * libmpeg3-dev: deleted #1041756 * libswe-dev: delete #1041757 * libx32lsan0: deleted #1042482 * netplan-generator: multiple, TBD * openrc: TBD, maybe triggerless M20? * pcp: delete #1041754 * pkg-config/pkgconf/pkgconf-bin: TBD, maybe M21? * printer-driver-foo2zjs: /lib/firmware/hp triggerless M20 * python3-expeyes: deleted #1041755 * systemd,udev: multiple, some deleted, others TBD The takeaway here is that the majority of cases are handled via deletion and we'll be finding solutions with the maintainers of those four packages. If you want to help mitigate these instances, you may add placeholder files or delete empty directories at any time. Adding diversions, maintainer scripts or triggers is something we need to consider at a later stage. Helmut test.sh Description: Bourne shell script
Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
On Wed, 31 May 2023 at 11:18, Helmut Grohne wrote: > > Hi, > > On Tue, May 30, 2023 at 11:53:00AM +0200, Helmut Grohne wrote: > > 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). > > I did some more analysis work here and have to admit that I know my data > model has a weakness that may result in false negatives. I'd have to do > a complete reimport of packages and eventually will, so for now I'm > dealing with incomplete data here. I note that content indices do not > cover empty directories, so you really have to download loads of .debs > to find these. > > Anyway, to gauge the problem, we're effectively looking for a > combination of packages A and B such that: > > * A ships an empty directory. > * That empty directory is a path affected by aliasing (either in /usr >or /). > * B also ships that directory (e.g. non-empty) in the "other" >representation of that path. > > While we have lots of empty directories in Debian, that third condition > trims down the numbers rapidly. A lot of empty directories (on amd64) > are one of the following: > * /lib > * /usr/bin > * /usr/lib > * /usr/lib/x86_64-linux-gnu > * /usr/sbin > > I've ignored these, because all of these are shipped in some essential > package and thus are not at risk of removal. /lib is kinda special in > this list as the idea of fixing this up actually is removing /lib (the > directory according to the dpkg database) and replacing it with a link, > but we'll have to treat that special anyway, so not relevant here. > > What remains is: > * /usr/lib/modules-load.d is empty in systemd and aliased by 6 >packages. This is the original instance that Andreas filed. If we >were not having this moratorium, the obvious fix were to move all >those 6 files. > > * /usr/lib/pkgconfig is empty in gretl libjte-dev libmpeg3-dev >libswe-dev pcp pkg-config pkgconf pkgconf-bin and aliased in >multipath-tools. Again, if it were not for the moratorium, we'd want >to fix multipath-tools. However, in this instance, we can "bypass" >the moratorium by moving /lib/pkgconfig/libdmmp.pc to >/usr/lib//pkgconfig/libdmmp.pc. It also seems to bundle a >shared library improperly. Chris Hofstaedtler confirmed this on IRC >and reminded us to never link any of those. The only package in the >archive that tries to do that (qemu) has its multipath integration >disabled, so this is not presently a problem. Probably, a better >solution is not not ship any header nor .pc file in multipath-tools >at all as that avoids accidental linking. > > * /usr/lib/systemd/system is empty in amazon-ec2-net-utils and aliased >in lots of other packages. This probably is a regression caused by >#1034212 and that directory simply needs to be deleted. > > * /lib/udev/rules.d is empty in python3-expeyes and aliased in lots. I >think this practically is a non-problem, because python3-expeyes >Depends: udev and udev ships that directory in that representation. >It will become a problem once udev canonicalizes paths. Jochen >Sprickerhof pointed out that python3-expeyes really needs this empty >directory in its postinst script. I presume it's for this script that's being called from postinst/postrm: https://sources.debian.org/src/expeyes/5.3.0%2Brepack-3/debian/eyes_udev.sh/ Could this be refactored instead? The rule seems static, ie, it doesn't need to change its content depending on the invocation as far as I can see from a cursory look. Is there any reason why it can't simply be shipped as a normal rule file in the package, instead of being written down to /lib via maintscripts? It doesn't seem like good practice to me to do that kind of modification of the vendor tree from a maintainer script. > * /usr/lib32 is empty lib32lsan0 and aliased in 5 packages. I think it >can be dropped there. This also bears another problem. Since removing >lib32lsan0 deletes /usr/lib32, we are left with a dangling /lib32 >link. > > * /usr/libx32 is empty in libx32lsan0 and aliased in libc6-x32. I think >it can be dropped there. Likewise, /libx32 can become dangling >otherwise. > > So yeah, this bug class is clearly not one to panic about. As we move > files from / to /usr, I expect this bug class to gain more occurences. I > am not aware of a generic solution and it seems diversions won't cut it. > If you can propose any generic workaround or recipe for this situation, > I'm all ears. The placeholder file sounds ugly, but might work. I agree, doesn't seem very worrying, and as far as I understand the observed impact so far is on testing infrastructure, but user functionality is not
Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
Hi, On Tue, May 30, 2023 at 11:53:00AM +0200, Helmut Grohne wrote: > 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). I did some more analysis work here and have to admit that I know my data model has a weakness that may result in false negatives. I'd have to do a complete reimport of packages and eventually will, so for now I'm dealing with incomplete data here. I note that content indices do not cover empty directories, so you really have to download loads of .debs to find these. Anyway, to gauge the problem, we're effectively looking for a combination of packages A and B such that: * A ships an empty directory. * That empty directory is a path affected by aliasing (either in /usr or /). * B also ships that directory (e.g. non-empty) in the "other" representation of that path. While we have lots of empty directories in Debian, that third condition trims down the numbers rapidly. A lot of empty directories (on amd64) are one of the following: * /lib * /usr/bin * /usr/lib * /usr/lib/x86_64-linux-gnu * /usr/sbin I've ignored these, because all of these are shipped in some essential package and thus are not at risk of removal. /lib is kinda special in this list as the idea of fixing this up actually is removing /lib (the directory according to the dpkg database) and replacing it with a link, but we'll have to treat that special anyway, so not relevant here. What remains is: * /usr/lib/modules-load.d is empty in systemd and aliased by 6 packages. This is the original instance that Andreas filed. If we were not having this moratorium, the obvious fix were to move all those 6 files. * /usr/lib/pkgconfig is empty in gretl libjte-dev libmpeg3-dev libswe-dev pcp pkg-config pkgconf pkgconf-bin and aliased in multipath-tools. Again, if it were not for the moratorium, we'd want to fix multipath-tools. However, in this instance, we can "bypass" the moratorium by moving /lib/pkgconfig/libdmmp.pc to /usr/lib//pkgconfig/libdmmp.pc. It also seems to bundle a shared library improperly. Chris Hofstaedtler confirmed this on IRC and reminded us to never link any of those. The only package in the archive that tries to do that (qemu) has its multipath integration disabled, so this is not presently a problem. Probably, a better solution is not not ship any header nor .pc file in multipath-tools at all as that avoids accidental linking. * /usr/lib/systemd/system is empty in amazon-ec2-net-utils and aliased in lots of other packages. This probably is a regression caused by #1034212 and that directory simply needs to be deleted. * /lib/udev/rules.d is empty in python3-expeyes and aliased in lots. I think this practically is a non-problem, because python3-expeyes Depends: udev and udev ships that directory in that representation. It will become a problem once udev canonicalizes paths. Jochen Sprickerhof pointed out that python3-expeyes really needs this empty directory in its postinst script. * /usr/lib32 is empty lib32lsan0 and aliased in 5 packages. I think it can be dropped there. This also bears another problem. Since removing lib32lsan0 deletes /usr/lib32, we are left with a dangling /lib32 link. * /usr/libx32 is empty in libx32lsan0 and aliased in libc6-x32. I think it can be dropped there. Likewise, /libx32 can become dangling otherwise. So yeah, this bug class is clearly not one to panic about. As we move files from / to /usr, I expect this bug class to gain more occurences. I am not aware of a generic solution and it seems diversions won't cut it. If you can propose any generic workaround or recipe for this situation, I'm all ears. The placeholder file sounds ugly, but might work. I still don't have any data on the multiarch variant of this problem. My local representation of the archive is unsuitable for analysing this and I have to perform a complete reimport first. Also placeholder files won't cut it here. Helmut
Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
On Tue, 30 May 2023 at 14:09, Helmut Grohne 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
Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
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
Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
On Tue, 30 May 2023 at 10:53, Helmut Grohne 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
Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
On Tue, May 30, 2023 at 11:53:01AM +0200, Helmut Grohne wrote: > Are there other kinds of resources in dpkg that can be shared like > directories? Thinking... Yes, regular files. How can files be shared? > Via Multi-Arch: same. Can that happen for real? Yes. I've attached an > artificial reproducer. Does it happen in the archive? I really cannot > tell yet. In effect, this is yet another bug class derived from Andreas' > directory-loss bug class. This new file-loss bug class is distinct from > the file-loss bug class that resulted in the moratorium. Sorry, for the double mail. That attachment thing is so easy to forget. Also dropped Luca as his email bounces. Helmut multiarchbug.sh Description: Bourne shell script
Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]
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). > - 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. 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. > - 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. For now, I am unconvinced that canonicalizing paths is the cure to this problem. To dpkg, a canonicalization looks like removing a file and adding a different file. Thus the deletion effect that Andreas reported may kick in while performing that canonicalization. It probably is not that simple though. As far as I understand it, dpkg first adds new files and then removes the old ones thus seeing that the directory it tries to delete is not empty (and we've seen it issue warnings about that case). To me, this means that we (or rather I) don't understand the problem well enough to judge it. It might be harmless, but it might be real. We shouldn't be scared, but "it probably works" may not be the best approach either. And then Andreas got me thinking. Before delving into that, I'd like to again express thanks to Andreas. When we see a bug from Andreas, can we please start with thanking him? Even if the bug ultimately is due to a limitation in piuparts (as has happened in the adduser case), his work (and that of other piuparts people such as Nicolas) still adds a lot of value to Debian. The occasional report that looks harmless initially tends to point at real problems more often than not. When he writes a mail, it is full of detail for looking at the issue. I ask us all to better appreciate that work. Let me do that now: Thank you Andreas, Holger and Nicolas! So let's stack-pop to where he got me thinking. A directory is a resource that can be shared between packages. Andreas demonstrated that removing one package may remove such a shared resource still being needed when another package references it via an aliased path. In effect, we break dpkg's reference counting of shared resources. Are there other kinds of resources in dpkg that can be shared like directories? Thinking... Yes, regular files. How can files be shared? Via Multi-Arch: same. Can that happen for real? Yes. I've attached an artificial reproducer. Does it happen in the archive? I really cannot tell yet. In effect, this is yet another bug class derived from Andreas' directory-loss bug class. This new file-loss bug class is distinct from the file-loss bug class that resulted in the moratorium. Etienne Mollier pointed out that "dpkg --verify" helps with diagnosing whether unexpected file deletion has happened on a particular system. It also reports other diagnostics and it does not consider any --path-excludes that have been configured via /etc/dpkg/dpkg.cfg, so use the output with a grain of salt. Also reinstalling the affected packages generally resolves the problem on a particular system. I wish I could give you numbers. I don't have them. I
