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 -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-python-debian-maint
