>>>>> "Helmut" == Helmut Grohne <helmut@subdivi.de> writes:
Helmut> Hi Sam,
Helmut> On Fri, Jul 07, 2023 at 08:50:49AM -0600, Sam Hartman wrote:
>>
>> 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.
Helmut> Reading both of your recent mails left me very confused. It
Helmut> is now obvious to me that we have a misunderstanding (at
Helmut> least one) and I am not exactly sure how we can get to a
Helmut> point where we talk about the same things.
Helmut> In your second mail, you classify 3C (the one about not
Helmut> changing the bootstrap protocol by adding aliasing symlinks
Helmut> to base-files) as a category 1 solution (where we leave some
Helmut> files in their aliased location to facilitate bootstrap). In
Helmut> reality, 3C is fully incompatible with category 1 as the
Helmut> premise of 3C is that every essential package has all of its
Helmut> files moved. This directly contradicts your TL;DR here.
Yes, we definitely have a misunderstanding.
I am at a conference today without much focus for Debian.
I did try to read your mail, but mostly my brain rebelled and argued
that's too complicated.
I'll try again tomorrow evening US time or Monday when I can give it
real focus.
Here's how we got to the understanding.
* I asked for a specific proposal to evaluate for 3C
* you responded:
>> 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
> Unfortunately, we're not yet done here. When (for instance) dash is the
>last package to move /bin/sh and such to /usr and you upgrade dash, dpkg
>notices that no package owns /bin anymore. Thus it helpfully deletes
>/bin (the symlink). You're not happy when this happens. We remember the
>silver bullet: diversions! So dash.preinst could dpkg-divert --no-rename
>--divert /bin.usrmerged -add /bin and dash.postinst could revert that.
>Unfortunately, such a diversion affects every package but dash and we
>want it exactly the other way round. So what we could do is pass
>--package dash-usrmerged (which must not exist). Then it'll actually
>keep /bin safe. Unfortunately, we don't know whether dash or bash will
>be the last package owning /bin, so both of them need this diversion and
>this is a conflict.
>And as if that wasn't enough, we also run into issues around hard links.
>As dpkg unpacks a canonicalized gzip, it notices that /bin/gunzip (which
>is scheduled for deletion) has the same inode as the new
>/usr/bin/uncompress (because gunzip and uncompress are hard linked). As
>far as I can see, all we get here is a warning and both files survive
>the unpack. It is not clear to me whether this happens by chance or
>reliably.
> dpkg: warning: old file '/bin/uncompress' is the same as several new
>files! (both '/usr/bin/gunzip' and '/usr/bin/uncompress')^
> dpkg: warning: old file '/bin/gunzip' is the same as several new files!
>(both '/usr/bin/gunzip' and '/usr/bin/uncompress')
>Given what I've seen, I'm fairly convinced that I haven't reached the
>bottom of it and I'm ready to conclude that this approach is fragile - a
>property that is most unwelcome when we deal with the essential set.
>So what's left is category 1. I looked into what the minimum set of
So, I assumed we were in a category 1 solution.
Because I read your message that you pointed to as a proposal for how 3C
worked, and before the concluding paragraph you said we were in a
category 1 solution.
I at least understand a category 1 solution.
It's fairly easy to reason about; I even think it's safe.
I don't like it for the architectural reasons I explained.
But well, if you tell me to go read a message that will contain a
proposal for what you want to do, and the last thing I read there--the
only thing that your analysis claims works--is category 1, that's going
to be left in my mind.
I really am trying to understand here, but this is exceeding the level
of complexity I can keep in my head.
That in and of itself is concerning: I'm well above average at being
able to work through this sort of thing.
I'll take a stab at your most recent email later.
Things I noticed already though:
* You are describing things in terms of changing.
Bootstrapping happens against a static archive. It might be easier to
analyze if you describe what the end state looks like in terms of
bootstrapping rather than changes to get there.
* You do not talk much about upgrades. Upgrades happen against a moving
archive.
There, talking about the changes, and why the changes are always safe
is important.
So for me, a 3C proposal would have two components:
1) An explanation of what the archive looks like at time of bootstrap
(and changes to any bootstrap programs) so I can reason about whether
bootstrap works.
2) An argument of safety of upgrades focused on the changes and why
those changes are safe both for unstable upgrades and for bookworm
upgrades.
* Your debootstrap changes seem overly complicated and would in and of
themselves push me against 3C. First, you don't seem to be thinking
about buster, which also needs to bootstrap usrmerged, doesn't it.
Second, is there a way we could simply change how debootstrap calls
tar?
I think asking debootstrap to not create the symlinks before is a big
ask.
Attachment:
signature.asc
Description: PGP signature