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

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636



Hello,

On Wed 15 Sep 2021 at 12:35PM +01, Simon McVittie wrote:

> On Wed, 15 Sep 2021 at 11:46:11 +0100, Simon McVittie wrote:
>> As for what that advice is, I'm open to suggestions, but I'm drafting
>> some possible wording, which I'll upload to
>> https://salsa.debian.org/debian/tech-ctte/ when I have a bug number
>> for it.
>
> Here it is:
>
> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

Thank you very much for this.

> This is a collection of various pieces of advice. I hope that this is
> sufficiently uncontroversial among the TC that we can improve the wording
> where necessary, then take a unanimous or close-to-unanimous vote
> "yes > further discussion" when we feel that it reflects consensus?

I think so, yes.

> If there are individual bits that are more contentious, then I suggest
> we vote on them as formally or informally as we are comfortable
> with, then make the formal resolution reflect the results of those
> votes; alternatively, we could kick out anything more controversial into
> a separate resolution if we need to.

Both those options seem reasonable.

> - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree
>   with what I've written here about the implications of #978636?
>
>   I've tried to be careful to distinguish between the Debian 12
>   stable release and the state of testing/unstable during the development
>   cycle; better wordsmithing welcome.

The implications of this distinction is the main point of contention in
the -devel discussions, so far as I can tell.  I've two things to ask.
You write:

>> - Because Debian 11 installations with the non-merged-/usr layout already
>>   exist, all packages in Debian 12 should be installable onto a non-merged-/usr
>>   system along with their dependencies, and work correctly on the resulting
>>   system.

(1) The reason for this, to put it a bit simplistically, is that we
don't require apt to perform the upgrade between stable releases in any
particular order, right?  Or are there other reasons distinct from this
one that I'm missing?  I think it would be good to state the thing about
apt (in better language than mine) in the text.

(2) Some people on -devel would seem to think that we can have smooth
upgrades from bullseye to bookworm without requiring support for
non-merged-/usr in every single package in bookworm, i.e., without
supporting non-merged-/usr for testing/unstable installations during the
current release cycle.

What smcv has been arguing for is the most conservative option.  But
which of the following is it the TC wants to say:

- we are sure that this is the only way to ensure smooth upgrades, such
  that it pretty much follows from our previous decision on merged-/usr

- we think there might be viable alternatives to requiring every package
  in bookworm to work on both layouts, but we aren't sure they are safe
  enough, so we're recommending a simple and conservative approach

- we think that ensuring non-merged-/usr testing/unstable installations
  work during this release cycle is reason enough to take this highly
  conservative approach

?

> - §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph
>   "If a suitable transition mechanism is not available by the time the
>   Debian 12 freeze is reached..." necessary, or is it implicit that
>   *obviously* we won't demand that the project carries on with merged-/usr
>   if it turns out not to be possible?

No, it's good to have that text.

> - §(Building packages): Does everyone agree with my interpretation of
>   what we agreed in #914897 and its implications? Do we need to make a
>   recommendation for the Debian 12 development cycle, or is it enough
>   to assume that the "middle" option that we resolved in #914897
>   continues to be our opinion?

I think that the other things said above mean that no-one would think
the situation with regard to building packages has changed since the
Debian 11 cycle.

>   I assume our advice power doesn't extend to unilaterally declaring
>   a class of bugs to be RC, but we can certainly advise the release team
>   and package maintainers that they *should* consider a class of bugs
>   to be RC; if they follow our advice, great, and if they don't, we can
>   consider whether we need to overrule in individual cases.

Agreed.

> - §(Moratorium on moving files' logical locations into /usr):
>   I think we should stop moving files into /usr on an individual basis,
>   at least until the consequences are fully understood, and perhaps for
>   the whole Debian 12 release cycle (after which, assuming merged-/usr
>   goes as we have recommended, maintainers can swap their logical location
>   without needing a transitional mechanism any more). Implementing
>   merged-/usr as the only supported layout means that moving files into
>   /usr on an individual basis is mostly unnecessary, because it has no
>   practical effect any more.

The case you make for this is convincing, given everything else said.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: