Re: Bug#767999: base-files: fails to install with pre-jessie debootstrap

[Guillem Jover <guillem@debian.org>]

Control: severity -1 serious
Control: retitle -1 dpkg: Correct fix breaks bogus assumptions in old debootstrap

On Fri, 2014-11-07 at 02:33:48 +0100, Cyril Brulebois wrote:
> Cyril Brulebois <kibi@debian.org> (2014-11-05):
> > But, from where I stand, several developers were actually checking facts
> > after I cherry-picked the patch in to the stable branch, and I decided
> > to wait and see where the situation was going. Apparently there are
> > several views on the matter, and without commenting on their respective
> > relevance, I'd like to emphasize several things:
> >  - Developers have limited free time.
> >  - Developers might be getting ready for the imminent freeze.
> >  - Uploading to stable means making sure the fix is right, rather than
> >    uploading hastily.
> >  - Uploads to stable don't appear magically on users' systems a few
> >    hours later; it takes a point release or users' having configured
> >    s-p-u in their sources.list; so I don't think any haste (see previous
> >    point) would help anyway.
> >  - Uploads to stable have to be reviewed by release team members, who
> >    might also be busy dealing with a flood of freeze-related requests at
> >    the moment.
> 
> Tests performed on an amd64 host running wheezy, debootstrapping amd64.
> 
> Well I bisected the archive and the last debootstrapable jessie release
> was at 20141102T221202Z; looking at the set of updated packages between
> that one and the next one, it looks like… dpkg got updated from 1.17.13
> to 1.17.21. And unsurprisingly reverting current jessie to dpkg 1.17.13
> makes debootstrap work again.

What's making the breakage in debootstrap surface is dpkg 1.17.20, commit
9ee62ecfc8937f24a82805a424564997042dd984. At least with my testing
using a patched debootstrap, and using --foreign + --second-stage to
inject a dpkg with the reverted commit.

> A few weeks or even days before the freeze doesn't quite seem to be the
> right time to introduce (not so) subtle changes in dpkg.

(So we need to actually freeze months in advance of the freeze… right.)

The above commit is a *correct* fix for a very old regression, to remove
a bogus package queue dependency stage in dpkg. The breakage in
debootstrap in older versions is due to incorrect assumptions, which
where fixed correctly (not worked around, contrary to what is mentioned
on its changelog) in 1.0.56. The change was:

-       x_core_install base-files base-passwd
+       x_core_install base-passwd
+       x_core_install base-files

where debootstrap was expecting that dpkg run to process base-passwd
first, even though it was passed last. This, on a call to dpkg using
--force-depends, for essential packages that do not have any kind of
dependency relationship between them, which makes any such assumption
be based on something far beyond undefined behavior.

> Reassigning it
> to dpkg for now; and cc-ing the release team because of things like the
> #768346 unblock request.

I'm going to revert the commit above (only in 1.17.x, it will be kept
in 1.18.x), because it is very minimal, just reintroduces again an
unnecessary package queue stage, and such regression is acceptable if
it makes buggy bootstrappers work again. But a fixed debootstrap (and
maybe cdebootstrap if that fails too) should really be pushed to stable.

Guillem