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: https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/77 -- 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