[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

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

> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

Many thanks for your work, and sorry for not participating earlier.

I agree with you that it would be good to send advice out sooner
rather than later.

I also agree with pretty much all you're saying in the text.

In particular:

> Questions for the committee:
> - §(Definitions and current status): Does everyone agree with my
>   characterization of where we are now?

Ack from me.

> - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree
>   with what I've written here about the implications of #978636?

I think I can follow the logic, and I agree with it.

> - §(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?

I think it should be included.

> - §(Testing and QA): Do we want to recommend this?

It does feel a bit like micro-managing to me. But the reasoning
makes sense. I'm fine with recommending it.
> - §(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 agree and I don't think we need a new recommendation.

> - §(Building packages): I almost wrote an extra paragraph about how
>   this class of bugs becomes a non-issue when merged-/usr is the only
>   supported layout - but actually it doesn't! If we consider building
>   packages while having /usr/local/bin/sed to be a supported thing you
>   can do, then we need to ensure that /usr/local/bin/sed doesn't get
>   hard-coded into the resulting package, and the steps you take to
>   make that happen are the same as the steps you take to fix this class
>   of bugs.

FWIW I think we've traditionally considered such /usr/local -related
issues as bugs in the build setup rather than in the packages.

> - §(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.

Agreed on the moratorium, mainly because of the unnecessity and the
error-prone nature of the moves. Sam brought up concerns about the
Replaces failure mode mentioned in the text, that part might need

On Mon, Sep 27, 2021 at 10:59:37AM +0100, Simon McVittie wrote:

> I am a little concerned that usrmerge is doing more intrusive surgery on
> a running system than even what's normal for an apt/dpkg-based upgrade,
> so I would prefer not to rule out designs that defer this action to a
> later time.

I share this concern.


Reply to: