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 <ferri...@gmail.com> 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
