Quoting Michael Biebl (2021-07-19 15:10:42)
> 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.
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,
/lib/systemd which will be fixed by an update to dh_installsystemd, and
/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.
> 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)/.
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?
This would mean that we only have to bear with the problems mentioned by
guillem until that move is complete, correct?
And another question: once there are no more files shipped by any package in
/(sbin|bin|lib)/ we can let base-file create the symlinks?
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature