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.
>>>>> "Helmut" == Helmut Grohne <helmut@subdivi.de> writes:
Helmut> Therefore, my premise of us agreeing on shipping the
Helmut> symlinks in base-files likely is wrong despite the number of
Helmut> vocal proponents.
I think we'd like to do that if we can make it work.
I think you convinced us the price of that is too high deep in the
message you quote below.
>> So I think that to argue for 3C you need a specific proposal
>> about what happens.
Helmut> https://lists.debian.org/20230517093036.GA4104525@subdivi.de
Ah thanks.
I will admit that mail didn't get the initial attention it perhaps
deserved.
And even reading it now I don't see a clearly articulated proposal for
3C.
I was put off by a number of things in the mail including the idea that
what we now call 3B would require encoding derivative-specific knowledge
into the bootstrapping protocol.
And so by the time you started talking about specifics of 3C I had
already disagreed with enough of the message that I had tuned out.
(I made those disagreements clear; my suspicion is that others who also
disagreed with other earlier parts of the message tuned out the 3C
specifics.)
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.
That is, there are some essential files that always remain in
non-canonical locations.
You also go through some analysis and make it clear that category 2 is
fragile:
> 2. Move and ship links. Since we unpack all essential data.tar before
> running the first maintainer script, having one package contain the
> compatibility symlinks is enough to fix the problem.
I agree with your analysis that category 2 is fragile.
I definitely had not payed adequate attention to this before, even
though I did read chunks of the message.
My understanding the argument for 3C is roughly the following:
>This gets me to the core of my argument: the way that a Debian chroot should
>look like should be described by the packages that get installed into the
>chroot and not by an outside tool. Yes, an outside tool is needed to do the
>installation but that tool should rely on the package metadata to make choices
>instead of encoding timestamp or release name dependent codepaths.
So it sounds like we are faced with two choices:
1) Keep some aliasing long-term in the data.tar files and get the
bootstrap described by the packages rather than by the bootstrap protocol
2) Change the bootstrap protocol and remove aliasing entirely.
I am firmly in camp 2. I think that unless we are going to fix dpkg to
support aliasing, we need to remove aliasing entirely.
Attachment:
signature.asc
Description: PGP signature