Re: 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/<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.
* /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
Reply to: