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

Re: Bootstrappable Debian - proposal of needed changes

On Wed, 16 Jan 2013 00:26:53 +0100
Jakub Wilk <jwilk@debian.org> wrote:

> * Johannes Schauer <j.schauer@email.de>, 2013-01-15, 19:18:
> >Build profiles extend the Build-Depends format with a syntax similar to 
> >architecture restrictions but using < and > instead.
> >
> >  Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !stage1>, tiny
> >
> >The drawback of this syntax is that Build-Dep parsing tools need to be 
> >updated to read/accept it, so uploads of source containing these 
> >annotations cannot be done until the dpkg in buildds at least parses 
> >it.
> Not only dpkg, but also wanna-build, sbuild, lintian, dak, and who knows 
> what else...

It's about which ones need to change. lintian response rates are not
likely to be a problem - once this gets approved. dak doesn't
necessarily need to do anything - most bootstrapping happens outside
the main archive to prepare the ground for a move into debian-ports.
Beyond that point, none of the bootstrapping support is required.

sbuild can use a specified bootstrapping dependency resolver, e.g. the
one used to test the proposal itself. (As could pbuilder.)

Again, as bootstrapping doesn't happen inside the main archive (due to
changed dependencies and changed functionality which would cause
problems), there isn't necessarily anything wanna-build needs to do
with this other than to allow the syntax & ignore it.

> We've been historically very slow at adapting our software to these kind 
> of changes:
> 1) Architecture wildcards were implemented in dpkg in January 2006. 
> pbuilder added support for them in February... 2011.
> 2) Support for the :any qualifiers in Build-Depends was added to apt in 
> February 2010, and to dpkg in March 2012; AFAIK it's still not supported 
> by wanna-build.

There are a lot of people willing to put a lot of time into this
proposal, not just those who have joined the thread so far. Patches,
patches and a few NMU's...

Simply having the mechanism in place and the critical tools updated
will be a major win. There will still be enough changes needed in the
rest of the packages.


Neil Williams

Attachment: pgpbOy7_8tIHV.pgp
Description: PGP signature

Reply to: