>>>>> "Sam" == Sam Hartman <hartm...@debian.org> writes:
Sam> TL;DR: It looks like if we do not want to encode merged /usr
Sam> into the bootstrap protocol, we must keep some aliases and
Sam> cannot move all files in data.tar. I think removing all
Sam> aliasing is important and so I am firmly in the camp of doing
Sam> usrmerge in the bootstrap protocol.
I was chatting with Klee Dienes this morning about this issue, and we
had an interesting discussion I'd like to share here.
I want to emphasize that Klee has not been following the discussion, so
if he comes up with interesting ways to think about things, great, but
he's not currently a participant in trying to come to consensus here.
It sounds like we've convinced ourselves we have some sort of technical
debt we're going to need to carry from the usrmerge transition, and we
probably will never be able able to get away from it:
1) In Bootstrap option 3B, we encode doing the usrmerge symlinks into
the bootstrap protocol. Even if we somehow later create the symlinks in
a data.tar, we need to retain this debt in the bootstrap protocol as
long as we want to be able to bootstrap versions of Debian that do not
encode things in data.tar.
2) If we take Bootstrap 3C category 1, and some files never get moved
to their canonical path, then we have technical debt we must maintain in
essential packages, basically for ever.
In effect, there is technical debt because the canonical locations of
some files differs from their canonical interface locations.
For example, /bin/sh will live at /usr/bin/sh.
And as long as that's true (we expect for ever), we have to say that
somewhere.
Okay, so how do we decide where to put technical debt?
Klee argued that one point of lower layers is to make things easier and
cleaner for layers above them.
I.E. there may be some magic in the bootstrap layer and that's good if
it makes things cleaner or more pure for the layer above (the essential
packages).
Similarly, we put complexity in essential packages and make it easier to
write non-essential packages.
We've seen this over the years.
For example, back in the day, bootstrap had to create devices.
It still has to arrange for a /proc and a /sys.
We managed to follow this principle by pushing devices down a layer
further effectively into the kernel and udev, and because of that
bootstrap is simpler than it used to be.
But Klee argued that putting this in bootstrap is nice because you can
handle it in one place rather than spreading it across every essential
package containir a binary that cannot move.
One assumption behind 3C at least initially is that we were avoiding a
combinatorial explosion in changes to bootstrap tool.
That's certainly true in
https://lists.debian.org/20230517093036.ga4104...@subdivi.de
That message assumes 3B is not really an option, and we're looking at
changes to number of bootstrap tools times number of releases of Debian
and all its derivatives.
But as we've explored, we've learned that the combinatorial explosion is
more like 2 (3 if you count cdebootstrap). Josh has agreed that we can
implement 3B in a small number of lines of code in the bootstrap
implementations, at least if we're willing to require people
bootstrapping pre-stretch to say they do not want merged /usr.
And so, we can concentrate the complexity of our technical debt into a
smaller number of places if we adopt 3B.
I also think it is possible (although unlikely) that as maintainer
scripts in essential packages change over the years, the number of
binaries affected by 3C category 1 may increase. I.E. we may find
ourselves moving a binary out of /usr back to /bin or being unable to
use that in a future maintainer script.
That seems like a mess to me.
I agree the set of circumstances where we need to do that is small, but
I think itmay be nonzero.
--Sam
signature.asc
Description: PGP signature
