Johannes Schauer Marin Rodrigues: > Quoting Michael Biebl (2021-07-19 15:10:42) >> [...] >> >> According to >> apt-file search -x '^/(lib|bin|sbin)' >> on my Debian sid/amd64 system, we have 1747 packages shipping 24583 >> files in those directories. > > more precisely, on amd64 unstable: > > /bin 247 files > /lib{32,64,x32} 83 files > /lib/firmware 2379 files > /lib/live 115 files > /lib/modules 17500 files > /lib/systemd 2221 files > /lib/udev 614 files > /lib/x86_64-linux-gnu 343 files > /lib/* 441 files > /sbin 547 files > > So most files come from /lib/modules, where only 14 packages are involved,
and debhelper's dh_installmodules that will need to be tweaked to look into /usr/lib/modules as well. But I have no idea if/when we would be ready for that and I will not be changing debhelper until we are ready to move these bits to /usr. Likewise for udev, here dh_installudev still uses /lib/udev and will continue to do so until I know that udev also checks /usr/lib/udev. If you are involved in udev or/and /lib/modules and know that they are ready to move to the relevant directory under /usr, then please feel free to file a bug against debhelper requesting that the /usr directory will be used in the future. Please do also note in that bug report whether you also want debhelper to automatically migrate existing files from /lib to /usr/lib. This should only be the case where we expect (almost) zero breakage from an automatic "unordered" transition. (NB: Please use a bug report as I will first be implementing this after the bullseye release and rely to this thread is likely to be lost in my inbox) > /lib/systemd which will be fixed by an update to dh_installsystemd, and Indeed, I have heard this request and the systemd maintainers confirmed to me that systemd in bullseye checks both /lib/systemd and /usr/lib/systemd. I have a branch lying around trying to support this. The main key feature missing is the migration of /lib/systemd -> /usr/lib/systemd (which needs to handle that both exist and merge them into one somehow). > /lib/firmware where only 36 packages are involved. The remainder then doesn't > sound so scary anymore as it only involves 656 unique packages and not 1747. > And again many of those remaining packages will be fixed by an update to > debhelper, correct? Given that 90% of source packages use dh, that would > reduce > the number to a very manageable size. > Indeed, about 90% of all packages uses dh according to trends. Though for good measure I thought I would explicitly answer the proposal (from another mail in this thread) that debhelper could move everything from /lib to /usr/lib: No, I will not support an unconditional move from /lib to /usr/lib via debhelper during bookworm. There are already two distinct examples in this thread for how this could break things. I will be sticking to "targeted" migrations where the major consumers have informed me that they are ready to support the migration. >> [...] >> >> Once we have this global switch to merged-usr, packages can bit by bit, >> completely independent, update their debian/rules to use --prefix=/usr >> and after a few years, we don't have any packages anymore installing any >> files in /. We could aid this process with a lintian check that flags >> packages that install files in /(sbin|bin|lib)/. > > So what what is actually the roadmap after the bullseye release? What is the > way forward? Should I rather file bugs with patches against individual > packages > to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we > already have a debhelper patch to do that move for us? > For some, debhelper will your problem but there will packages that will need manual migration. As I see it, there will *not* be "the debhelper patch to fix them all" - even if there will /some/ debhelper patchers that will fix "most of them". Related, I have no intention of supporting / maintaining a rewrite of "--prefix/PREFIX" parameters to configure/make/cmake or whatever. (Not saying anyone proposed it - but mentioning it as another "there will definitely be manual clean up" data point). ~Niels