Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Hi,
On Fri, Jun 09, 2023 at 09:57:21PM +0200, HW42 wrote:
> Did you consider just having one package keep one dummy file in /bin?
> While this isn't elegant it sounds much less complex than diversions and
> tricky pre-depend loops, etc.
The dummy file is not necessary. Debian packages can ship empty
directories. Having any package ship /bin (empty or not) is fully
sufficient to prevent dpkg from removing it.
> I might be very well missing something here (for example maybe it's
> really essential that no files remain in /bin, even not a dummy file).
> But in the other branch of this thread you welcomed "dumb" questions, so
> here you go ;]
Yeah, I consider the property that nothing ships anything in aliased
locations an important one. So let us go down for the consequences of
not doing that.
So some package will keep shipping /bin. It does't really matter which,
but clearly this package must be part of the essential set (otherwise
you could remove it and with it /bin would be deleted). This is cool for
upgrades, but less so for bootstrapping tools.
One of the approaches to making bootstrapping work was adding the
symlinks to some data.tar. That has been category 2 from my earlier
mail. We definitely cannot add /bin as a directory to one package and
/bin as a symlink to another (unless using diversions), because the
resulting behaviour is dependent on the unpack order when used with
dpkg. Also any bootstrap tool that unpacks with tar -k (such as
debootstrap) requires changes to support this. So this pretty much
precludes completing the transition in a way that just unpacking all
data.tar of essential packages gives you a working chroot. In effect,
this requires a proposal to change the bootstrap protocol (category 4)
in order to make sense.
There is a loop hole that I ignored here. While /bin cannot be both a
directory and a symlink at the same time, we can upgrade it. So if we
somehow managed to get one and only one package to contain /bin as a
directory, we could upgrade that to a symlink. Unfortunately, any
external package that still ships stuff in /bin breaks this. In effect,
any addon repository or old package can break your system.
The other way of seeing us keep /bin as a directory is to not
canonicalize (i.e. category 1). Then we'd simply keep (wlog) /bin/sh in
/bin and not move it to /usr.
Can you elaborate in what way you see protective diversions as adding
complexity? It can be as simple as:
dpkg-divert --add /bin --divert someplacewedontcare --package base-files --no-rename
We'd add this to one package and everyone else can issue Pre-Depends.
The benefit we gain from keeping /bin is not clear to me (beyond
avoiding a diversion). At this time, it seems to me that doing that
either requires changing all bootstrapping tools (in yet unspecified
ways) or never canonicalizing all paths (according to the dpkg
database).
Now I'm wondering what I am missing here.
Helmut
Reply to: