On Mon, 2 Jan 2017 12:49:59 -0500 Rich Freeman <ri...@gentoo.org> wrote:
> However, in this case why would we want to rule out sets, "and all the > other shenanigans?" We've already established that a single stable > request bug can apply to multiple package-versions, so why not allow > full dependency specifications? If there is a set that describes what > needs to be stabilized in an atomic operation, then what is the value > in breaking it down into a million separate =-only atoms? That rather complicates validation. Mostly, because if you declare a list of dependencies, if any of them is a range, the subgraph of that specific atom becomes variable, not constant. Which means you may have omitted one of the possible dependencies from one of the possible subgraphs that an AT/Keyworder will see. This IMO would mostly negate the utility of submitter defined lists of specifications. In that, by making the submitter resolve it all, its either "good" or "bad" Instead of leaving the person doing the testing in a confused state about which packages are expected to be used. The sets as defined should either work, and the person doing them should get each and every one working as expected, or none of them should, and it should be pushed back to the submitter to fix their specification. Levity in tester interpretation is likely to introduce side effects.
pgpm4inpuSDyM.pgp
Description: OpenPGP digital signature
