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

Re: Bootstrappable Debian - proposal of needed changes

On Thu, 17 Jan 2013 21:51:32 +0100
Wouter Verhelst <wouter@debian.org> wrote:

> On Thu, Jan 17, 2013 at 09:34:16AM +0100, Johannes Schauer wrote:
> > Hi,
> > 
> > On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote:
> > > If wanna-build is updated to support these two fields, then I imagine
> > > it can run the bootstrapping dependency algorithm. While you wouldn't
> > > want to upload a package to the debian.org archive when the
> > > architecture is as yet incomplete, the same isn't true for the
> > > debian-ports.org archive.

Much (most?) bootstrapping is going to be cross-building which
wanna-build doesn't do. Native builds are not possible for new
architectures and the many iterations inherent in bootstrapping
will suit cross-building better when working with emulation or models.

> It already needs to do build-dependency tracking, marking packages as
> "can't be built yet because build-depends aren't there yet" all the
> time. That's exactly the sort of thing you need to be doing, no?

Not quite. Many dependency resolvers exist (for better or worse, we
have a lot of choice), wanna-build isn't a particularly lightweight
resolver as it isn't designed to be just a resolver. wanna-build isn't
designed to do cross-building and there are other tools which have
already been patched to improve their cross-build support (like sbuild
and rebuildd).

Not all Debian build tools need to do any real work due to the
bootstrapping fields - most of the main tools can simply allow the
fields and ignore them.

> > After all profile built packages successfully rebuilt
> > fully, *all* source packages of the strongly connected component are
> > rebuilt. This is to make sure that every source package was built once
> > with all build dependencies available.
> If you have enough information on what a package needs to build
> properly, you wouldn't need to do this.
> But I agree that's a pretty big "if".

... and the information changes with every upload of every package,
even ones which weren't part of the dependency chain at the previous
version  ... 

(which makes cross-building even more likely just to have a chance of
new architectures / emulated architectures keeping up)

> Your build profiles are essentially creating additional "variants" of a
> particular binary package.

.. variants which do not have to be uploaded anywhere in particular,
neither ftp-master not debian-ports. Once bootstrapping is complete,
all the packages are going to be rebuilt with none of the
bootstrapping profiles enabled anyway.

The typical problem with these variants is that almost nobody else is
using this particular configuration of the package and even upstream
probably rarely test their package in this mode. Packages which depend
on the modified package will almost certainly never have been tested
against the changes made for bootstrapping purposes.

There are significant risks in letting bootstrapping packages out of a
tightly controlled bootstrapping chroot / machine.

It's not just about build-depends, it is about not getting into the
situation where bugs get reported to the main package BTS which relate
solely to one or other package being in a bootstrap-only configuration.
These might not be so hard to identify in the package being modified
but when packages which depend on that package start misbehaving,
bugs get a lot harder to triage. Let's not make work for people if we
can avoid it, especially if those people are maintaining packages
which aren't directly involved in bootstrapping.

Bootstrapping support can be implemented without explicit support in
the main archive software (other than allow-and-ignore) and,
personally, I think that is the correct way to manage things.

Only certain tools need to be modified and we should resist the
temptation to generalise a mechanism which is likely to cause confusion
and bugs in previously working software.


Neil Williams

Attachment: pgpDa37AmFirO.pgp
Description: PGP signature

Reply to: