On Wed, 31 May 2023 at 11:18, Helmut Grohne <hel...@subdivi.de> 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/<triplet>/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 impacted, right? If needed, placeholder could be added, or the testing infrastructure could be taught to ignore them. Kind regards, Luca Boccassi
