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 |