On Mon, Jan 2, 2017 at 12:59 PM, M. J. Everitt <m.j.ever...@iee.org> wrote: > On 02/01/17 17:49, Rich Freeman wrote: >> On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric <ken...@gentoo.org> wrote: >>> On Thu, 29 Dec 2016 17:23:58 +0000 >>> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: >>> >>>> Because it isn't... Are set names atoms? Are package names without an >>>> associated category atoms? >>> Sets /are/ still dependency specifications, in that reading, just like >>> || ( ) groups are dependency specifications, and lists of atoms are >>> dependency specifications. >>> >>> Hence, this is an example of in my mind why "atom" is a *better* descriptor >>> than "dependency specification" >>> >>> Because it rules out sets and all the other shenanigans. >> 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? >> >> If the process becomes further aided by automated tools then using the >> same dependency specifications as PMS/etc would allow the same code to >> be used to identify candidate PVs to stabilize. >> >> Of course in the most typical case you're stabilizing exactly one PV, >> but I'm not sure we need to limit the syntax simply because that is >> all that is required in the most common case. >> > I don't think we're writing new tools to do this, we're simply using the > existing ones better. So, a list of explicit ebuilds by > Category/Package-Version is what's desired (I believe). But I'll defer > to kensington/ago who are the ones really using this system in anger ... >
Even if you don't write new tools, I don't see how sets would cause a problem. A set is just a list of dependency specifications, which is what we're otherwise storing. There is no rule against putting 100 specific package versions in either. If you have a set that describes something like a KDE stabilization I'd think that this would be preferable to listing all the KDE packages in the box. But, if somebody can see a problem this would cause I'm all ears. -- Rich