Re: Bootstrappable Debian - proposal of needed changes
On Thu, Jan 17, 2013 at 11:34:55PM +0100, Johannes Schauer wrote:
> 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).
I think you misunderstood me here; my 'it' in the above quoted paragraph
was referring to wanna-build, not the tool which does the actual
compilation.
Wanna-build (in the current state of affairs, that is, without this
implemented) already needs to track (regular) build-dependencies. To
me it wouldn't seem too much of a stretch (or too difficult) to add the
required changes so wanna-build can track what's needed to do the
bootstrapping of an architecture. This way, you could tell it "hey, we
have a stage1 compiler and libc." It would then populate its needs-build
list with things that can be built with those (probably stage1 perl and
some other things), and have its buildds build those. Once done, you'd
see the next profile happen.
Now, admittedly I never looked at the wanna-build code, but I've been
working with wanna-build for years now and have a fairly good knowledge
of how it operates through that. So I might be wrong, but I don't think
I am.
[...]
> > > 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.
Yes, exactly. That's what I meant with "big if" :-)
> 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.
Yes, I can understand that. In fact, that's why I suggest the above.
If it is trivially easy to do bootstrapping, we could preform a regular
fully automated bootstrapping test as a matter of course. We already
perform (semi-)regular full-archive rebuild and piuparts checks, and do
lintian runs over the whole archive, so I don't see why we couldn't do
this, too.
> But to go with your idea I have another proposal:
[...other syntax snipped...]
> 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.
Fair enough.
--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.
Reply to: