Re: Bootstrappable Debian - proposal of needed changes
+++ Ian Jackson [2013-01-16 13:50 +0000]:
> Johannes Schauer writes ("Bootstrappable Debian - proposal of needed changes"):
> > 6. Conclusion
> > =============
> > - do the proposals for the needed fields sound convincing? Can they be
> > improved? Do they have fundamental flaws?
> I haven't spotted anything hideously wrong. I have three suggestions
> for changes:
> * Packages should explicitly declare which profiles they support.
> This should be done with a Profile field in the source stanza
> of debian/control.
I agree this is a really good idea. They could be inferred from
parsing the build-deps line, but profiles that don't actually change
the build-deps could exist and they would be undiscoverable without a
field like this. I did think about putting this in the spec mail, but
decided it was long enough to be going on with.
> * It should be made explicit in the spec that building occurs with
> zero or one profile, not several.
This is something to ponder. We could decree that and it would
simplify some things. But I think there are good reasons to consider
what we gain from relatively granular profiles which brings along with
it the likelihood of needing to specify more than one.
> * The concrete syntax in build-depends should not use < > but rather
> reuse the architecture qualification syntax.
> This takes the < > metacharacters and reserves them for build
> profiles. Metacharacters are very scarce and should only be used when
This is a good point. I really don't care what the syntax is so long
as as it represents the semantics we need. The current syntax was
suggested by the dpkg people, and it has been shown to be sufficient.
If we can make it work sensibly without using a new metacharacter then
that's fine by me.
[snip very useful attempt to try and define a spec].
We do need something explicit like this writing down, so thanks for
doing that. In fact I'll copy it over the wiki page. The details of
this need a decision on whether more than one can be specified at a
time or not, before we can finalise them.
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM