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

Re: tech-ctte: more on merged-/usr

On Tue, 2022-07-19 at 13:42 +0100, Luca Boccassi wrote:
> On Tue, 2022-07-19 at 13:03 +0100, Simon McVittie wrote:
> > On Sun, 17 Jul 2022 at 14:21:30 +0100, Luca Boccassi wrote:
> > > By keeping
> > > the buildds in umerged-usr state for Bookworm, and switching them as
> > > soon as it is released, it seems to me we can avoid caring about
> > > [packages which are misbuilt on merged-/usr] at all.
> > 
> > So when do you plan to start operating bookworm and sid buildds as
> > merged-/usr? Toolchain freeze day? Transition freeze day? Full freeze
> > day? Release day?
> > 
> > I don't really like the idea of post-release bookworm security updates,
> > etc. being built in chroots that are explicitly unsupported.
> Unstable would be built on merged-usr from release day, given from any
> point before that packages built on unstable might migrate to bookworm.
> And before release day, there's no such thing as a bookworm buildd,
> right? Everything is built in unstable?
> The issue with having packages that end up in bookworm built on merged-
> usr is that the class of bugs you described above go from harmless to
> dangerous. We are intentionally not imposing any order on the dist-
> upgrade, and we are not requiring any special tool to do the dist-
> upgrade, as per approved decision. But this means we'd need to bne
> really sure that no such bugs exist, because a package built on merged-
> usr might get installed and configured by apt before usrmerge does and
> thus run, albeit briefly, on an unmerged-usr system. Of course
> guaranteeing such bugs do not exist is difficult, given only a fraction
> of the archive has any autopkgtest cover at all, let alone full
> coverage, as you noted.
> On the opposite end of the spectrum, we can be reasonably sure that
> packages built on unmerged-usr buildds do work fine on merged-usr
> systems, because that's the status quo, and if there was some issue
> we'd have known by now (and indeed some were found and fixed in the
> past).
> Now if post-release we wanted to switch the bookworm security and p-u
> buildds to merged-usr because as you said otherwise they'd be in an
> unsupported setup, that would be fine and safe I believe, because they
> would be installed on already merged-usr systems, so as far as I can
> tell the risk mentioned above wouldn't apply anymore.

Any more thoughts on this, Simon?

In the meanwhile, I opened an MR to get reportbug to include if the
system is unmerged-usr in the report:


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Filesystem: the layout is not merged-usr
Architecture: amd64 (x86_64)

Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: