Hi Sam, * Sam Hartman <hartmans@debian.org> [2023-07-07 08:50]:
TL;DR: It looks like if we do not want to encode merged /usr into the bootstrap protocol, we must keep some aliases and cannot move all files in data.tar. I think removing all aliasing is important and so I am firmly in the camp of doing usrmerge in the bootstrap protocol.
We seem to agree on the goal (if by "removing all aliasing" you mean stop shipping any files in /bin and /lib), but I firmly disagree with your premise. Let me elaborate.
So, my understanding of the specific proposal is that: We in are in category 1:1. Don't move. We just keep those files that require a particular location (such as /bin/sh or the dynamic loader) in their non-canonical location. As such, maintainer scripts will be able to run and perform the conversion to symbolic links afterwards.
In Helmut's mail to which you are referring, he later explains that
the bootstrap categories come from two orthogonal questions:
Q1. Who is responsible for the top-level symlinks?
Q2. Are there any packages which install files through a top-level
symlink, i.e, an aliased path?
We want the answer of Q2 to be No. The answer to Q1 has, as far as I
can tell, three alternatives:
Q1a. Symlinks are created by the bootstrap tool early on
Q1b. Symlinks are shipped in a package (e.g. base-files) and will
be created in the initial unpack phase
Q1c. Symlinks are created by a usrmerge conversion, either in a
maintainer script in the configuration phase or in the final
cleanup phase by the bootstrap tool
Q1a puts us in Category 4 in Helmut's taxonomy (or as I am going to
call it from now on, HC-4); I'll skip that discussion for now.
Q1c defers the symlink creation to such a late stage that we run
into the ABI problems outlined in other mails; basically, this is
the answer that may force us to ship the dynamic loader in /lib{64,}
and the POSIX shell in /bin forever, and firmly entrench the
usrmerge conversion into our bootstrap process. In my opinion, we
can rule this out completely, because it does not finish the
usrmerge transition as much as hide it away in a dark place where
nobody dares to look. We would end up in HC-1 or HC-3.
Q1b is where it gets interesting, because the way our bootstrapping
protocol currently works, *all* packages will be unpacked first, and
only *then* the configuration phase begins and maintainer scripts
are executed. This means that we *can* move all files to their
canonical paths, because the top-level symlinks will be created
juuust early enough. Depending on the answer to Q2, we end up in
HC-1 or HC-2.
Q1b is my favorite, because it allows us to move the files, finish
the transition, and regain the property that a Debian system is
fully described by package metadata (HC-2).
Q1b has one important failure mode while there is any package left
in the essential set which has not moved its files to the canonical
location: as the initial unpack order is undefined, it is possible
that such a package gets unpacked early enough to create real /bin
or /lib directories, which would then conflict with the subsequently
unpacked top-level symlinks. I think this is the "fragility" other
people keep referring to. Any other usrmerge transition
problem will affect Q1a as much as Q1b, because after the unpack
phase, both are in the exact same state.
The simplest solution for the unpack problem would be to amend the
bootstrap protocol and have base-files be unpacked first. As soon as
all packages have properly transitioned and moved their files to
/usr, we are free to remove that requirement again, because the
unpack order will no longer matter.
Alternatively, we could move all files except for the few critical
ones (/bin/sh, dynamic loader), and then have a coordinated flag day
upload where we add the base-files symlinks *and* move all remaining
files, but this feels quite a bit more fragile to me.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Attachment:
signature.asc
Description: PGP signature