| 1 |
>>>>> On Fri, 27 Jun 2014, David Leverton wrote: |
| 2 |
|
| 3 |
>> It should be treated like a regular USE flag for dependency |
| 4 |
>> resolution. So in your example, the dependency would be satisfied. |
| 5 |
|
| 6 |
> That makes that sort of dependency fairly useless then - it forces |
| 7 |
> the user to mess with their configuration, but it doesn't actually |
| 8 |
> influence what gets installed. If the package is somehow |
| 9 |
> incompatible with git-svn being available and working (OK, it's a |
| 10 |
> pretty contrived example...) then the dependency doesn't do anything |
| 11 |
> to help the situation. If we're OK with that then fine, but it's a |
| 12 |
> potential point of confusion for ebuild authors. |
| 13 |
|
| 14 |
I agree that such dependencies are not very useful, so probably they |
| 15 |
won't be used in the tree. |
| 16 |
|
| 17 |
Now, should we add complicated special cases to the spec and to |
| 18 |
package managers, in order to forbid something that devs are unlikely |
| 19 |
to do? IMHO we shouldn't, but keep things simple instead. |
| 20 |
|
| 21 |
(Besides, it is always possible that we overlook some valid usage |
| 22 |
case. If we forbid it in the spec, we're stuck with this. If we make |
| 23 |
it tree policy, we can change it easily.) |
| 24 |
|
| 25 |
> [...] (Perhaps we could have a repoman check instead?) |
| 26 |
|
| 27 |
Sure, a repoman check sounds fine. Although I believe that there is |
| 28 |
little danger that such deps will be added inadvertently. |
| 29 |
|
| 30 |
Ulrich |
Archives