On Mon, 2021-07-19 at 15:10:42 +0200, Michael Biebl wrote: > Am 19.07.21 um 03:36 schrieb Guillem Jover: > > What I've also said multiple times, is that > > merged-usr-via-moves-and-symlink-farms could have been implemented in > > a fully automated way, by debhelper, w/o requiring any maintainer scripts, > > all with full cooperation and managed by dpkg, with .debs shipping > > actual tracked pathnames
> What you propose is, that each and every package does its /usr-merge > transition on its own. This only works, if packages are independent (enough) > so this actually works. > Unfortunately this is not the case. Take PAM for example. You can't just > recompile src:pam and have debhelper automatically move all files to /usr. > This would break all packages that install a PAM plugin. You have a > transition here, involving many packages. > Same is true for udev rules, systemd service files, basically every package > that provides interfaces/hooks to other packages is affected. > So it's not that simple unfortunately. You can't fully automate that. Not at all. pam or whatever we transition via cooperation from dpkg, would be kept compiling using the directories it currently uses, and debhelper would simply move the objects on the .deb from «/» to «/usr», and create the compat symlinks. That means pam, and any plugins migrated or not, would still be available in the current pathnames causing no breakage. This part would be done automatically. And as I've said elsewhere, removal of the compat symlinks would require manual intervention (at the maintainer discretion), at some later time, to modify the configured installation paths (which is something that cannot be automated in debhelper, due to packaging overrides and similar), at which point it can be decided whether to declare say a local pam flag day, or add the needed Breaks and similar, or add support to pam to look in both pathnames to avoid the two previous items. > 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. There are *many* such entangled transitions hidden in > there, so I fear this is not manageable. See my comment above, and josch reply. > As Luca pointed out, even distros with a much stricter governance model were > not able to do that. Well if they did it poorly, no wonder, I guess. > The /usr-merge transition as described and decided on in the TC bug, seems > to me is the only viable way forward. I obviously disagree. > Yes, it does break dpkg -S, but your idea of using a list of mapped paths as > in [1] seems like an entirely reasonable approach to solve this. Did you miss the section in the mail you are replying where I mention that f.ex. dpkg tools (dpkg, dpkg-divert, u-a) missing to then detect file conflicts, or files disappearing on moves, or dpkg-deb -x (or tar) destroying merged-/usr-via-aliased-dirs systems? All these, including dpkg -S (which BTW also breaks after paths have been moved, as when say bash ships as /usr/bin/bash, then dpkg -S will also fail to find the expected /bin/bash), are currently affecting any system being installed by the default installer, or ones having been switched by the usrmerge hack. > 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)/. The same can be said about my proposal, except that then dpkg is kept in the loop, the transition is done safely by dpkg as part of individual package upgrades, instead of having to use something off-band and as disturbing as usrmerge during upgrade, on dpkg's back w/o any cooperation from it… Regards, Guillem
