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

Re: Bootstrappable Debian - a decision is needed, patches exist

On Wed, Oct 23, 2013 at 07:01:36PM +0100, Wookey wrote:
> +++ Steve Langasek [2013-10-19 20:46 -0700]:
> > Hi Johannes,

> > My understanding is that all build-dependency loops in the archive can be
> > broken with a single additional stage (stage1), so only one added profile
> > and one added build-dependency field would be required. 

> No, that's wrong. We need stage2 for at least toolchain bootstrapping.

You need three distinct stages of package builds for this?  AIUI the first
stage of toolchain bootstrapping is always done outside the package build.

> And practical usage has shown that distinguishing between bootstrap, cross
> and test deps is genuinely useful.  Doko has also expressed this opinion,
> and in is one of the few people that has used this seriously.  So I really
> wouldn't want to go back to the simple 'Build-Depends-Stage1: <stuff>'
> implementation.  I agree with Guillem on this.

Distinguishing between test deps and build-deps is purely an optimization,
it doesn't enable any fundamentally new capabilities.

Cross-deps don't seem to be covered by the current proposal AIUI.  I agree
that we're sorely missing a way to specify toolchain build-dependencies that
need to change depending on whether you're doing a native or cross build;
from my perspective this is even more important than bootstrapping, since
you bootstrap a port once but run into packages with
cross-toolchain-dependencies on an ongoing basis.  But while profiles let us
dodge unsatisfiable build-deps on things like <gcc-4.8:armhf>, they don't
provide the semantics to let us pull in <gcc-4.8-arm-linux-gnueabihf:amd64>
in its place.  Is anybody working on that problem?  I think Colin's
suggestion was that we might be better off having logic in apt's build-dep
resolver to magically map build-deps in certain cases, but I don't know that
this has been written down as a fleshed-out proposal anywhere yet.

> > Yes, it could
> > bitrot, but it's better than not having any of the data in the source
> > packages at all.  And if someone really finds this inelegant and insists
> > that we should extend the syntax of the Build-Depends field, let them step
> > up and make that happen instead of pointing at grandiose plans they're not
> > making any effort to implement.  A Build-Depends-Stage1 field requires no
> > support from dpkg in the archive to implement.

> Right, but we have now written the code for the better scheme, so the only
> issue is actually putting it in dpkg, which applied just the same to
> Build-Depends-Stage1.  That original scheme had an advantage when nothing
> better had been done or proposed.  Now it has none.

> Guillem has now put this back on his list and promised to put somethig in
> soon, so I hope we'll see something which is both reasonably flexible and
> implemented very soon.

Even if this were implemented in dpkg today, you still can't merge this
bootstrapping information into the Build-Depends fields of the packages in
the archive until the autobuilders can cope with it.  That means not only
does dpkg have to be able to parse it, so do apt, wanna-build, and (IIRC)
sbuild.  When will that be done?

The Build-Depends-Stage1 field requires no changes to the syntax of existing
fields and no changes to the archive infrastructure.  It could be added to
packages immediately (or, you know, a year and a half ago).

Build profiles may be a better overall design, but this design doesn't buy
us very much in practical terms AFAICS.  It just introduces more delays. 
Don't let the perfect be the enemy of the good.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: