Re: Second take at DEP17 - consensus call on /usr-merge matters
On Wed, 28 Jun 2023 at 20:38, Helmut Grohne <helmut@subdivi.de> wrote:
>
> Hi,
>
> thanks for all the valuable feedback on the huge DEP17 thread. As
> promised, I looked into condensing that discussion into something
> shorter. That shorter thing still has more than 3000 words and is
> available as source at
After seeing the 3k words, I now regret having asked you for an update
a couple days ago :-D
> Consensus proposal #1:
>
> This updated DEP17 is a complete representation of the known and
> relevant problems and known mitigations under discussion at the time
> of this writing.
+1
> Consensus proposal #2:
>
> The primary method for finalizing the /usr-merge transition is
> moving files to their canonical locations (i.e. from / to /usr)
> according to the dpkg fsys database (i.e. in data.tar of binary
> packages). dpkg is not augmented with a general mechanism
> supporting aliasing nor do we encode specific aliases into dpkg.
+1
> Option #3a:
>
> The bootstrap protocol shall be changed to contain a task for
> merging /usr as is done in debootstrap in a release-dependent way.
>
> This is an instance of M16 from DEP17.
>
> Option #3b:
>
> The bootstrap protocol shall be changed in unspecified ways to
> support the /usr-merged systems in a way that does not depend on
> matching the codename or suitename.
>
> This is an instance of M16 from DEP17.
>
> Option #3c:
>
> The bootstrap protocol shall remain unchanged. Therefore, all
> essential packages need to move their files out of aliased locations
> and the aliasing symlinks are to be installed from a data.tar of a
> binary package such as base-files.
>
> This is M2+M11 from DEP17.
>
> While a few people including Marco d'Itri and Sam Hartman have argued in
> favour of exploring the space of #3b, no proposals have emerged in the
> interim. The proposal in #3a has three significant limitations:
> * It creates compatibility issues when combining old a new suites
> unless changes to bootstrapping tools are backported to older
> releases.
I have mentioned this a few times already, but: we already did this
last year, I backported a bunch of changes in debootstrap to bullseye
and even buster, to add support for usr-is-merged. I do not see this
as a "significant" limitation, merely some additional busywork that
I'm happy to take care of.
> * It becomes a whack-a-mole, since we need to add codenames of every
> derivative to every bootstrapping implementation.
As we have learned recently, the project is fine if know-broken
changes percolate down to derivatives, it is fine to just document it,
and it is fine to let said derivatives do their own downstream changes
to deal with it as they see fit. I don't see why this case would be
any different. Sauce for the goose is sauce for the gander.
> * It breaks bootstrapping from snapshot.d.o and therefore breaks tools
> such as debbisect and debootsnap.
Sure, some combinations might be broken, but do we even guarantee that
any combination from any point of snapshot.d.o would always work?
Seeing that just today there was an unintentional (and quickly fixed)
regression in an essential package that broke installation altogether,
it seems to me the answer is no. Hence as above, sauce for the goose
etc etc.
> While the first of these limitations is shared with #3b, the others are
> not and that would make #3b more attractive to me if there was a
> concrete proposal to evaluate. The one about unpacking base-files first
> seemed the most concrete to me, but it has the downside of imposing a
> permanent cost on bootstrapping tools even though we only need that
> behaviour temporarily, which seems like too bad of a trade-off to start
> with in my opinion. Did I miss a relevant proposal for modifying the
> bootstrap protocol?
>
> On the flip side, there is a demo for #3c showing that we can move most
> of the things except for a hand full of packages and then flip the
> switch (for bootstrapping) in unstable by uploading those packages
> simultaneously. The biggest downside of this probably is the inherent
> fragility of this approach. Even if this is extensively tested before
> uploading chances are good that we still break something unforeseen in
> the process.
>
> Can I get more feedback from those who rather not have #3c implemented as
> to how you see things moving forward?
Changing the bootstrap tools seems much safer. It is just two tools,
and we need backports to [[[old]old]old]stable just for debootstrap as
that's what is used on the buildd infrastructure, and the other will
be up to the maintainer how far back to go. The risk is contained to
the bootstrapping case, which _usually_ is a relatively 'safe'
environment, in the sense that there is some expectation that it might
fail and the runner is expected to deal with it. Moving the risk to
the upgrade phase of every single Debian instance in existence seems
inherently more risky to me.
> Option #4a:
>
> The finalization of the /usr-merge transition shall not rely on
> changes to dpkg, because such changes cannot be relied upon during
> the upgrade to trixie.
>
> This is denying M1 and M3 from DEP17.
+1 totally opposed to have _any_ dpkg changes in the way of any resolution
> Option #5a:
>
> The paths used to interface with update-alternatives remain
> unchanged.
>
> This is M13 from DEP17.
Yeah, let's punt it for now, and deal with the big items first.
> I also hope that this mail results in detailed disagreements that I can
> use to refine DEP17 and to base further research on.
I hate to ask, given you have already put a lot of work on the linked
document, but a very rough ballpark estimate in how much work it would
be to implement each solution (where not available yet) would be very
useful for making decisions, I think. If it's too much effort feel
free to just tell me to go chop some wood.
Thanks for the update!
Kind regards,
Luca Boccassi
Reply to: