[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: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

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

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

Reply to: