[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Second take at DEP17 - consensus call on /usr-merge matters



Hi,

On Wed, 2023-06-28 at 21:37 +0200, Helmut Grohne wrote:
> Among these options, the first has a working prototype (debootstrap),
> but it is unclear how that extends to use of snapshot.d.o and how to
> make it work with debootsnap and debbisect as those tend to use a
> suite name rather than a codename.

debootstrap allows using suite names as well. As their meaning changed
over time, the changes for conditional merged-usr also made debootstrap
extract the Codename from the Release file in case a user specified a
suite name.  These days there are a few other changes that might depend
on the release (identified by the codename).

As pointed out on IRC, this might not work for the combination of
"unstable" and using snapshot.d.o, but in principle that could be
handled by looking at the Release's Date field as well (but, meh, not
sure if we need that).

>  * It becomes a whack-a-mole, since we need to add codenames of every
>    derivative to every bootstrapping implementation.

Well, shouldn't it already have become whack-a-mole then?  debootstrap
has the code for many years and is widely used after all... It doesn't
seem to have been a problem in practice as there haven't been
complaints since this was implemented AFAIK.  (Possibly users just
specify --no-merged-usr manually if needed; no idea.)

> Introduction
> ============
[...]
> Regardless of what strategy we end up choosing here, we will likely
> keep some of the temporary changes even in the `forky` release to
> accommodate external repositories and derivatives.

There should be no additional work for derivatives.  merged-/usr is not
really something a Debian-based derivative can opt-out of and if some
distribution did so (say because of warnings in dpkg or for other
reasons), it's their own problem...

Ansgar


Reply to: