1 |
* Tom von Schwerdtner (tvon@×××××.org) wrote: |
2 |
> Hey all, |
3 |
> |
4 |
> Some people have suggested that they would like to be able to set some |
5 |
> USE variables for specific apps.....examples escape me, but I know it has |
6 |
> been brought up. |
7 |
> |
8 |
> Anyways, I was thinking something along these lines would work: |
9 |
> |
10 |
> ---- |
11 |
> # Global settings |
12 |
> USE = "this that other etc" |
13 |
> |
14 |
> # App specific |
15 |
> USE-mozilla = "!this !that foo" |
16 |
> ---- |
17 |
> |
18 |
> Basicaly, the syntax would be "USE-<appname>". This portion should be |
19 |
> simple enough to impliment, however the variables pose more of a problem |
20 |
> since you dont want to have to repeat all of the normal USE settings for a |
21 |
> specific app and most of the time you just want to specify a USE setting not |
22 |
> to use (hence the !'s). Special vars might be good here too, like |
23 |
> "defaults" to inherit all the global USE settings...or "no-defaults" to |
24 |
> ignore them all... |
25 |
> |
26 |
> .....thats the general idea....comments? |
27 |
|
28 |
Hey Tom, |
29 |
|
30 |
I've heard these requests too; however, adding more complexity doesn't |
31 |
seem, to me, like the thing to do. Why not the user read the ebuild prior |
32 |
to emerging, and modify her USE variables to taste? I thought this was |
33 |
standard practice, in fact. |
34 |
|
35 |
The current state encourages ebuild reading prior to merging, understanding |
36 |
of how Portage works, and maintains existing elegance. |
37 |
|
38 |
More practically, would it even be feasable to add such a feature to |
39 |
Portage at this stage in its lifecycle? |
40 |
|
41 |
Very Best Regards, |
42 |
Gontran |