Hi, On Thu, Jan 17, 2013 at 09:51:32PM +0100, Wouter Verhelst wrote: > > I'm not sure if wanna-build is the right tool to do this > > Why not? > > 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?
No. The tool that actually does the build, doesnt have to keep track of which dependencies are met at any point (but is of course free to check anyways). Which source package is compiled when and which binary packages exist and are installable at which point is known by the dependency analysis tools that produced the build order. If the calculation of the build order went right, then at each compilation step, all dependencies will be met. So the tool doesnt have to have a way of knowing "can't be built yet because build-depends aren't there yet". The tool is of course free to check anyways ;) It is also entirely possible to include the algorithms *into* the build tool and make them part of the process that figures out the "can't be built yet because build-depends aren't there yet". Maybe this is what you meant. I mean in theory you could even drive a trivial dpkg-buildpackage wrapper or similar instead of something more fancy like wanna-build. I didnt think much about the actual implementation of this step yet (aka: what tools to use to do the actual compilation). > > 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". There is a higher guarantee of a source package having built properly if it was built with all its dependencies in place because this is also how it had been normally built for other arches for (possibly) years. Bootstrapping is the exception and not the rule, so it is easy that the additional information you mention goes out of sync. By trading a bit more CPU time for a recompilation, the bootstrapper will have to worry less about having produced binary packages with a reduced feature set. > > We have thought about this issue but did not manage to come up with > > a global solution. A solution would require a way to depend on > > "features" of a package and therefor create an overcomplicated > > dependency syntax which would not justify its purpose. > > I'm not sure I agree with that. > > Your build profiles are essentially creating additional "variants" of a > particular binary package. I imagine we should be able to come up with a > syntax for the build-depends header which would allow one to declare you > depend on a particular variant of a binary package. > > Let's say something like the following (extending the syntax as > suggested by Ian Jackson earlier): > > Build-Depends: foo (profile:stage1 >= 1.3) [profile:stage1], foo (>= 1.3) > [!profile:stage1] > > Essentially, with this syntax I'm saying that to build a the package > which contains this build-dependency header, under normal circumstances > you'd need the package "foo" at version 1.3 or above, as built with no > profiles enabled; but if you enable the "stage1" profile for this > package, you can use the "stage1" version of the "foo" package instead. > > I don't think this is too confusing or complicated, and I think it makes > sense to add the profile to the version information in this manner; a () > qualifier for a package could then be interpreted as a statement of > *what* a package needs to comply with (version or profile of the > build-dependency), whereas a [] qualifier would state *when* we need a > particular build-dependency (architecture or profile of our *current* > build). Sure, anything is possible. I just again worry about this being too fragile and the additional data not being maintained because it is only seldom used. But to go with your idea I have another proposal: Ian Jackson was proposing a syntax which combined build profile names and architecture names to create one format which describes restrictions on both: Build-Depends: foo [amd64 i386] [!profile:stage1 profile:stage2] The MultiArchCross spec [1] already defines a syntax on how to explicitly depend on a binary package of a specific architecture. Namely, the ":" character is used as a separator of package name and architecture in the same way it is used for the :any and :native qualifiers needed for dependencies on M-A:allowed packages. So somebody is able to write: Build-Depends: bar:amd64, baz:native This is not currently supported in Debian but I heard it is in Ubuntu and I also heard cross compilers need to depend on binary packages of a specific architecture, so I guess this syntax needs to be supported by wanna-build sooner or later? Ians proposal put profile names and architecture names in the same pot. Therefor, it would be more consistent to use the same syntax which is already used to depend on a package of a specific architecture for depending on a package of a specific profile. Your line above would become: Build-Depends: foo:stage1 (>= 1.3) [profile:stage1], foo (>= 1.3) [!profile:stage1] Or foo:profile:stage1... Maybe the namespace and the label should be separated by something different than a colon in this case... Well, you get the idea. Not saying that doing any of this is a good idea, but I do think this syntax is more consistent and goes more with Ians idea of reusing the architecture qualification syntax. cheers, josch [1] https://wiki.ubuntu.com/MultiarchCross -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130117223455.GA16317@hoothoot