On Tue, Dec 06, 2011 at 11:34:28PM +0100, Micha?? G??rny wrote:
> On Tue, 6 Dec 2011 14:27:48 -0800
> Brian Harring <ferringb@...> wrote:
> > Simple example of why sets.conf cannot be relied on:
> > 
> > # xorg sets
> > [x11-module-rebuild]
> > class = portage.sets.dbapi.VariableSet
> > world-candidate = false
> > variable = CATEGORY
> > includes = x11-drivers
> > 
> > Or using a literal overlay example:
> > [jmbsvicetto sets]
> > class = portage.sets.files.StaticFileSet
> > multiset = true
> > directory = ${repository:jmbsvicetto}/sets/
> > 
> > So for any non portage PM, we'd have to translate portage class name 
> > paths, know the actual signature of the target (VariableSet for 
> > example), and perfectly emulate that- also emualate the 
> > ${var:default} interpolation.
> 
> We wanted to replace that class with some global/generic vars, noone
> was interested in cooperating. Especially the-one-whose-name-shall-
> -not-be-spoken-aloud-or-he-will-come-with-his-metaphores.

It's not that people aren't interested in sets, it's that the 
proposal of trying to mutate sets.conf into something people 
would be happy with is fucked from the get go.  Keep in mind pkgcore 
actually already supports the basic format (minus a few tweaks, this 
is pkgcore's raw ini format for when people need to screw w/ the 
absolute guts of it).

It is *not* a good format for compatibility; adding a couple 
global/generic class names (basic schemas) still leaves open the 
ability for people to force PM specific class settings, getting us 
right back into the original criticism I leveled- specifically leaving 
PM's having to continually play "emulate the portage api".  It's a 
shitty situation to be in, and not one alternative PM authors are 
going to willingly walk into.

sets.conf isn't viable; this was known when it was originally forced 
in.

package.[setname] for a static list of atoms is a fairly good start; 
profiles could stack it (reusing existing stack logic), and 
repositories could grow metadata/sets/[name] as a base to use for 
example.

One thing people need to agree on /prior to implementing this/, is how 
overlays will interact here.  Can they mutate an existing set?  etc.

Other thing to note, we should probably use a different name than 
package.*; set.* is saner.  If we use package.*, a naive 
implementation could interpret package.use* as a set.

~harring