Re: Bootstrappable Debian - proposal of needed changes
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
Reply to: