Re: Bug#1050001: Unwinding directory aliasing
On Fri, Aug 18, 2023 at 02:39:48PM +0100, Simon McVittie wrote:
> On Fri, 18 Aug 2023 at 07:57:14 +0100, Ian Jackson wrote:
> > I think we can probably fix it by backing out this change, and then
> > doing usrmerge the traditional Debian way by making changes to
> > debhelper, so that we move the files package by package, in the .debs.
>
> What do you consider to be the end goal of this proposal?
Getting usrmerge done (either completed or done for) in a finite time.
If you read the decent DEP-17 update, continuing on the current path:
* will require man-years of work
* will for sure not be finished for trixie
* there's too much unclear pieces that might be not done for forky even
if preparations are in for trixie
while doing by what Ian (and others earlier) have proposed can reach
either end state (merged or non-merged) with very little work.
> If I understand your proposal correctly, it is to return all Debian
> systems to their traditional (let's say circa 2010) layout, and then
> restart the transition differently. Imagine for a moment that the
> usrmerge package, debootstrap --merged-usr, etc. had never existed,
> and all Debian systems were in their 2010 state (or equivalently, that
> your proposed revert has happened and we are now ready for the second
> stage of your plan).
Yes, and here is how it would go in my view:
* dpkg-fsys-unrunmess is completed (currently it's in a PoC state, working
but needs to be speeded up, polished, and above all tested)
* dpkg is uploaded with postinst calling dpkg-fsys-unrunmess
* packages shipping something in /lib (or preferable /usr/lib/),
packages defining a trigger for these parts, etc, get rebuilt with
Pre-Depends: dpkg (== version above); almost all required changes can
be done with logic in dpkg-dev alone.
Note that such moves _can_ be done as the moratorium is now moot as
all its reasons are gone.
* ... all files from /lib /bin (that are not required interface, such
as /bin/sh -- which can be symlinked) are moved within a week from
the first upload. Rather than taking two+ Debian releases!
> If we carry out this transition package-by-package without central
> coordination ("the traditional Debian way"), it seems to me that the
> best we can achieve is for /bin, /sbin, /lib* to be symlink farms,
> consisting of symlinks that are either owned by the same package that
> owns the symlink target, or are unowned from dpkg's perspective and are
> created by maintainer scripts.
That'd be the resulting state of the steps I mentioned above. Once /lib
/bin (or preferably, /usr) are empty save for symlinks, they can be merged
safely.
> /bin would still represent non-trivial on-disk and/or in-dpkg-database
> state, and we would still potentially have other issues triggered by
> the directories being distinct from one another (like the one discussed
> by the tech committee in #911225, which was exactly a regression caused
> by having moved a library in the traditional Debian way).
Such a move would be 100% safe as dpkg has full knowledge of the filesystem
layout. The regression in #911225 applies only to usrmerge-aliased layout.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
⢿⡄⠘⠷⠚⠋⠀ ./configure --host=zx-spectrum --build=pdp11
⠈⠳⣄⠀⠀⠀⠀
Reply to: