[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)



Hi Guillem

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
I'm convinced this view is way too naive and not implementable in practice (and yes, openSUSE is a data point that confirms that)

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.

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. As Luca pointed out, even distros with a much stricter governance model were not able to do that.

The /usr-merge transition as described and decided on in the TC bug, seems to me is the only viable way forward.

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.

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)/.




Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858331#33


Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: