Updating python-debian support for build profiles

[Johannes Schauer]

Hi Stuart,

Quoting Stuart Prescott (2014-09-04 16:11:17)
> > This is implemented in a similar way of the dpkg patch for this: get
> > everything inside the <> brackets and then split by '>\s+<'. Though notice
> > that there should be a space between each <> block but you write '>\s*<'
> > which also allows no space at all.
> 
> hmm... is there a point in enforcing strictness on what is accepted? (Writing 
> it back out is done with strict conformance)

Probably there is no point in python-debian being strict about it because dpkg
is already strict about it.

> > > * as a result, we need to return a list of restrictions not a single
> > > restriction
> > 
> > Especially after the change we were unsure whether the "restriction lists"
> > should in fact be "build profile lists" but I guess we stick to the former.
> 
> Given these names will be exposed in the API, it would be good to have a 
> definitive "this is what we are going to call this" prior to making the API 
> publicly available.

I think that there is any gain in yet another renaming. So please use the terms
from the current version of the spec.

Restriction formulas are made from restriction lists.

> > > * I propose flattening the representation of each restriction from
> > > (enabled, (namespace, label)) to (enabled, namespace, label)
> > 
> > There are no namespaces anymore. 
> 
> likewise here -- the terminology "namespace" and "label" came directly from 
> the text in the wiki, but I'm not sure what to call thing that used to be 
> called "namespace.label". The closest I can see is "term" or perhaps 
> "restriction"; however, the former seems to be used to include the ! while the 
> latter is not actually used.

And restriction lists have terms.

> Is "term" the component such as "cross" or "!stage1" from which a restriction
> list is built? (Or is it "cross", "stage1" not including the "!"?)

Whereas each term is a (possibly negated) build profile name.

> Some clarity in this will make life easier for implementers and will lead to
> a more consistent interface in each implementation which will be a good
> thing.  (See, for instance, the confusion between "archive area" and
> "component" in policy, dak, Release, sources.list, apt, ...)

I agree. Do you think that the current way it's written down is unclear? I
tried to clarify above but I had hoped that this was already clear from the
wiki page.

cheers, josch