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: > > So the reasoning behind adding the override to debootstrap in -- > > variant=buildd mode is twofold. > > > > From a very practical perspective, it means it's supereasy to allow all > > those builds and tools you mentioned to run in unmerged-usr, there's no > > extra config or code changes required anywhere else, it just works. > > Shouldn't `debootstrap --no-merged-usr` also have this behaviour for > other variants? If a "larger" component like autopkgtest or piuparts > explicitly asks for non-merged /usr in some other variant (in practice > it would usually be minbase or default for those tools), it seems like > debootstrap should do as it says, even if that means going into the > unsupported mode. > > --variant=buildd currently implies --no-merged-usr, so this would still > provide the behaviour you want for buildds. > > For the older suites where absence of an explicit option is equivalent > to --no-merged-usr, this flag-file wouldn't be created anyway, because > it's an older suite that doesn't need it? > > (I've commented as such on debootstrap!71.)
Initial feedback on IRC was to keep these separate given the result is unsupported, but I can certainly change that as you suggested, will update the MR shortly. > > From a strategic point of view, catching all those class of bugs you > > mentioned is not trivial > > It'll be even less trivial if we remove the ability for autopkgtest and > piuparts to (create chroots that will) test this code path, which is > why I asked for an opt-out mechanism in the first place... Yes that is understood and agreed, the intention was always to let the CI tools do that, there's some back and forth on how exactly to make that happen but nothing unsurmountable. > > 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. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
