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