| 1 |
>>>>> On Tue, 8 Feb 2011, Ryan Hill wrote: |
| 2 |
|
| 3 |
>> If we really implemented it in this way, then I fear that it would |
| 4 |
>> be difficult for users to find out what flag combinations they can |
| 5 |
>> use. |
| 6 |
|
| 7 |
> The guideline I usually follow is that flags depending on another |
| 8 |
> flag being set (eg. png needs X) should be ignored (you can always |
| 9 |
> ewarn). For flags that conflict with other flags (exactly one of |
| 10 |
> many, if-this-not-this) use REQUIRED_USE. Does that make sense? |
| 11 |
|
| 12 |
Yes, in my opinion it does. Should the devmanual be updated |
| 13 |
accordingly? (There is already bug 353624 open for it.) |
| 14 |
|
| 15 |
Maybe we also need a guideline that whenever possible, ebuilds should |
| 16 |
accept the default USE flags from our profiles as a valid combination? |
| 17 |
Or, in the exceptional case when that isn't possible, a package.use |
| 18 |
entry should be added to profiles. |
| 19 |
|
| 20 |
> If we went with your second extreme, if I wanted to disable X for |
| 21 |
> emacs, I'd also have to add 10 additional flags to package.use on my |
| 22 |
> system to get it to work. If we were doing that for every package |
| 23 |
> I'd switch distros. |
| 24 |
|
| 25 |
That's what I thought too. ;-) |
| 26 |
|
| 27 |
In other words: If an ebuild has n USE flags and the package can be |
| 28 |
configured in m different ways, then it is _not_ the goal to allow |
| 29 |
only m of the 2**n possible flag combinations. |
| 30 |
|
| 31 |
Ulrich |
Archives