>>>>> "Helmut" == Helmut Grohne <helmut@subdivi.de> writes:
I believe I'm up on this discussion to at least comment on the consensus
calls you discuss in the mail.
Except where noted below, I support your reading of consensus.
Helmut> Consensus proposal #1:
Helmut> This updated DEP17 is a complete representation of the
Helmut> known and relevant problems and known mitigations under
Helmut> discussion at the time of this writing.
I have read the mail, not the full updated DEP, so I cannot yet ack
this.
Helmut> When we get into mitigations, consensus is hard to come
Helmut> by. My impression is that we have roughly two camps. One is
Helmut> in favour of major changes to dpkg and the other is not.
I think you might get a more clear consensus if you phrase that in terms
of whether people are willing to wait for major changes in dpkg.
If the dpkg maintainer were to merge aliasing support, I haven't seen
anyone objecting strong enough to try and override that maintainer
action for example.
Helmut> There also is a minority arguing in favour of doing
Helmut> both. I've kinda ruled out that option already as we get the
Helmut> downsides of both without any further benefit in return.
I agree there is not sufficient support to try and force this.
I don't think there is a strong enough consensus to push back against
anything reasonable the dpkg maintainer did in this space.
Helmut> My impression is that the (vocal) majority falls into the
Helmut> latter category. The major alternative here is getting into
Helmut> a state where all paths shipped in binary packages are not
Helmut> aliased (dubbed M2 in DEP17). Therefore, I propose a second
Helmut> consensus call.
Helmut> Consensus proposal #2:
Helmut> The primary method for finalizing the /usr-merge
Helmut> transition is moving files to their canonical locations
Helmut> (i.e. from / to /usr) according to the dpkg fsys database
Helmut> (i.e. in data.tar of binary packages). dpkg is not
Helmut> augmented with a general mechanism supporting aliasing nor
Helmut> do we encode specific aliases into dpkg.
Helmut> I recognize that this is not unanimous, but I think we still
Helmut> have sufficient consensus on this. I suspect that maybe
Helmut> Simon Richter and a few more would disagree here. If
Helmut> consensus fails, we may have to put this to a vote.
I agree, there is a rough consensus on this.
Helmut> Once that is settled, the next big question is how to handle
Helmut> bootstrapping. We had a number of people arguing in favour
Helmut> of changing the bootstrap protocol. Such changes can be
Helmut> classified into generic changes and release-dependent
Helmut> changes. A release-dependent change enhances bootstrapping
Helmut> tools with knowledge of available releases and adapts
Helmut> behaviour in release-specific ways that are encoded into the
Helmut> bootstrapping tool. As it stands, the only bootstrapping
Helmut> tool that has been enhanced in this way is debootstrap and
Helmut> that support is limited to Debian and two derivatives. The
Helmut> category of generic changes includes imposing an ordering on
Helmut> initial unpacks (e.g. base-files first). Others are in
Helmut> favour of not changing the bootstrap protocol. In that view,
Helmut> some data.tar will have to ship the symbolic links and all
Helmut> other essential packages need to have their files
Helmut> canonicalized.
Ah, this was really helpful, because it allowed me to understand that at
least you and I haven't even been thinking about the problem space the
same.
Let's explore whether debootstrapping tools need to have release
knowledge at all.
Support for creating a merged /usr installation was first added in
debootstrap 1.0.83 in September of 2016.
It was enabled by default in 1.0.85 in October of 2016.
So, everything since stretch has supported merged /usr.
1) Do we actually still need to support boostrapping things older than
stretch at all using modern bootstrap tools?
If you're really installing something that old, can't you use a
container image to use an older bootstrapping tool?
2) Even if we do, I think it's okay to say that you need to specify
--no-merged-usr when installing something older than stretch, just as
you need to specify that if you want a buster, stretch, or bullseye
version that is not merged /usr.
So my proposal is to modify the bootstrap protocol, and unless an
administrator specifically requests a non merged /usr system, then merge
/usr.
My initial analysis is that you're making this more complicated than it
needs to be.
My assumption here is also that the change needed to the bootstrap
protocol is the same as the change that debootstrap has been doing for
years.
If there are additional changes that would be harmful when bootstrapping
stretch, buster, bullseye, or bookworm,
I agree it gets more complicated.
I'd like to understand those changes though.
Attachment:
signature.asc
Description: PGP signature