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

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



Hi!

On Fri, 2014-11-07 at 08:30:39 +0000, Michael Tautschnig wrote:
> On Fri, Nov 07, 2014 at  8:34:49 +0100, Guillem Jover wrote:
> > Control: severity -1 serious
> > Control: retitle -1 dpkg: Correct fix breaks bogus assumptions in old debootstrap
> 
> I'd say the bug title ought to be "Correct fix makes bug in base-passwd
> surface."

No, see below.

> [...]
> 
> I do agree with all the dpkg reasoning and in a way I'm grateful that dpkg made
> this bug surface. But really there shouldn't be any such dependency on the order
> of configuration of base-files and base-passwd.

There needs to be one, and that's part of the problem of bootstrapping
a system. I agree with Santiago that adding an implicit Depends
completely defeats the point of Essential, and that's a wrong fix.

> > > 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.
> 
> I think you might want to hold off on this revert. See
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767999#73
> 
> and Adam's kind testing of that patch.

The reasoning there is not correct, Santiago is right except for the
part where he might be trying to justify this through policy, because
bootstrapping a system is currently outside the realms of policy. Many
of the packaging system invariants do not hold there.

What debootstrap does is more or less this (with other setup
sprinkled in between):

  Extract .debs
  - dpkg-deb --extract
  Install core .debs
  - dpkg --install --force-depends
  Unpack required .debs
  - dpkg --unpack --force-depends
  Configure required .debs
  - dpkg --configure --pending --force-configure-any --force-depends
  Install dependencies of pre-depencies for base system .debs
  - dpkg --force-overwrite --force-confold --skip-same-version --install
  Install base system .debs
  - dpkg --force-overwrite --force-confold --skip-same-version --install
  Configure base system .debs
  - dpkg --force-confold --skip-same-version --configure -a

There are several stages where for example preinst scripts have never
been run for any Essential packages, --force options are used all
over the place; this should be a very clear indication debootstrap has
to operate in a completely different environment and conditions. For
example, dpkg will fail flat out if there is no status file, and that
cannot be shipped in the .deb; dpkg will create it if not present in
its postinst (but that's really too late when bootstrapping a system),
so debootstrap needs to create these instead, and this is a very similar
situation to the one with the passwd file, but in that case a better
solution is to hardcode an install order and offload the work to
base-passwd. Someone needs to know that that file has to be created
somewhen or by something.

ISTR there was in the past discussions (AFAIR either in d-d or a dpkg
bug) about trying to move the bootstrapping information into packages
in a bootstrap maintscript or similar. Those would need to be run from
outside the chroot, so that we are not back to the problem of implicit
assumptions and ordering though. And the expectations on the external
environment would need to be specified, for example assuming just POSIX
utilities.

*That* would be a proper fix to the problem of the implicit ordering,
would also be a generic solution independent of the distribution or
derivative, or current set of packages, and we might be able to have
(possibly) a more generic debootstrap. I can try to draft something
up if people are interested in this for jessie+1.

Thanks,
Guillem


Reply to: