| 1 |
On Tue, Dec 06, 2011 at 11:34:28PM +0100, Micha?? G??rny wrote: |
| 2 |
> On Tue, 6 Dec 2011 14:27:48 -0800 |
| 3 |
> Brian Harring <ferringb@×××××.com> wrote: |
| 4 |
> > Simple example of why sets.conf cannot be relied on: |
| 5 |
> > |
| 6 |
> > # xorg sets |
| 7 |
> > [x11-module-rebuild] |
| 8 |
> > class = portage.sets.dbapi.VariableSet |
| 9 |
> > world-candidate = false |
| 10 |
> > variable = CATEGORY |
| 11 |
> > includes = x11-drivers |
| 12 |
> > |
| 13 |
> > Or using a literal overlay example: |
| 14 |
> > [jmbsvicetto sets] |
| 15 |
> > class = portage.sets.files.StaticFileSet |
| 16 |
> > multiset = true |
| 17 |
> > directory = ${repository:jmbsvicetto}/sets/ |
| 18 |
> > |
| 19 |
> > So for any non portage PM, we'd have to translate portage class name |
| 20 |
> > paths, know the actual signature of the target (VariableSet for |
| 21 |
> > example), and perfectly emulate that- also emualate the |
| 22 |
> > ${var:default} interpolation. |
| 23 |
> |
| 24 |
> We wanted to replace that class with some global/generic vars, noone |
| 25 |
> was interested in cooperating. Especially the-one-whose-name-shall- |
| 26 |
> -not-be-spoken-aloud-or-he-will-come-with-his-metaphores. |
| 27 |
|
| 28 |
It's not that people aren't interested in sets, it's that the |
| 29 |
proposal of trying to mutate sets.conf into something people |
| 30 |
would be happy with is fucked from the get go. Keep in mind pkgcore |
| 31 |
actually already supports the basic format (minus a few tweaks, this |
| 32 |
is pkgcore's raw ini format for when people need to screw w/ the |
| 33 |
absolute guts of it). |
| 34 |
|
| 35 |
It is *not* a good format for compatibility; adding a couple |
| 36 |
global/generic class names (basic schemas) still leaves open the |
| 37 |
ability for people to force PM specific class settings, getting us |
| 38 |
right back into the original criticism I leveled- specifically leaving |
| 39 |
PM's having to continually play "emulate the portage api". It's a |
| 40 |
shitty situation to be in, and not one alternative PM authors are |
| 41 |
going to willingly walk into. |
| 42 |
|
| 43 |
sets.conf isn't viable; this was known when it was originally forced |
| 44 |
in. |
| 45 |
|
| 46 |
package.[setname] for a static list of atoms is a fairly good start; |
| 47 |
profiles could stack it (reusing existing stack logic), and |
| 48 |
repositories could grow metadata/sets/[name] as a base to use for |
| 49 |
example. |
| 50 |
|
| 51 |
One thing people need to agree on /prior to implementing this/, is how |
| 52 |
overlays will interact here. Can they mutate an existing set? etc. |
| 53 |
|
| 54 |
Other thing to note, we should probably use a different name than |
| 55 |
package.*; set.* is saner. If we use package.*, a naive |
| 56 |
implementation could interpret package.use* as a set. |
| 57 |
|
| 58 |
~harring |
Archives