1 |
Ryan Hill wrote: |
2 |
|
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
>> Ryan Hill wrote: |
5 |
>> > Though I'm still not sure what happens when a package is in two |
6 |
>> > unrelated sets.. |
7 |
>> > |
8 |
>> > @gnome: |
9 |
>> > RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2" |
10 |
>> > |
11 |
>> > @xfce4: |
12 |
>> > RDEPEND="gnome-extra/gnome-screensaver" |
13 |
>> > |
14 |
>> > package.use: |
15 |
>> > @gnome opengl |
16 |
>> > @xfce -opengl |
17 |
>> |
18 |
>> I suppose we could use the order that they are listed in package.use |
19 |
>> to apply the incremental stacking, so opengl would be disabled since |
20 |
>> @xfce comes after @gnome. |
21 |
> |
22 |
> I guess I'll need to stop sorting my package.use then. :p |
23 |
> |
24 |
> But yeah, I have no better idea. If someone really needs to lock down |
25 |
> a USE flag on a pkg they can put the pkg atom itself into p.use. |
26 |
> |
27 |
Indeed, although a more natural approach might be to take whichever |
28 |
dependency is more specific (in the case where the user hasn't otherwise |
29 |
expressed a preference, and there is a conflict.) The more specific dep |
30 |
implies a closer relationship (although a warning would be useful ofc.) |
31 |
|
32 |
Another way to express preference or association might be useful too, |
33 |
although a category heuristic would also aid automated decision-making (the |
34 |
set is being considered, so I'm guessing we know, which packages are listed |
35 |
in it; can easily query if not.) The fallback would be the simple position |
36 |
in the list. |
37 |
|
38 |
While this might sound like yet more special-casing it's the kind of thing |
39 |
that delights users ime, since it means less for them to worry about, and |
40 |
only runs in the case where the decision is not clear from the |
41 |
configuration and the tree. IOW something to specify as a 'may' rather |
42 |
than 'undefined.' |
43 |
|
44 |
(I still feel the same about losing 'world' ofc *sniff* ;) |