1 |
On Saturday 24 February 2007 13:17, Ciaran McCreesh wrote: |
2 |
> On Sat, 24 Feb 2007 13:09:40 +0900 Jason Stubbs <jstubbs@g.o> |
3 |
> | Okay, I must be missing something here. If package foo can work with |
4 |
> | either bar or baz equily as well but not both, why should it force an |
5 |
> | artificial preference? |
6 |
> |
7 |
> For consistency. Installing a package with identical USE flags should |
8 |
> give the same result on all systems. |
9 |
> |
10 |
> | Also, if packages should not specify dependencies based on what is |
11 |
> | installed, the semantics of || ( ) would need to be changed such that |
12 |
> | the first non-masked packages is always installed. |
13 |
> |
14 |
> No, || ( ) has legitimate use for switchable dependencies. For example, |
15 |
> if a package can use either curl or wget, and it can switch at runtime, |
16 |
> RDEPEND="|| ( curl wget )" is fine. Similarly, if a package needs |
17 |
> either tetex or ptex at compile time, DEPEND="|| ( tetex ptex )" is |
18 |
> correct. |
19 |
> |
20 |
> | The only reason I can see for the above is to be able to have |
21 |
> | non-broken binary packages. However, that can be addressed by |
22 |
> | replacing *DEPEND in binary packages with their resolved forms. |
23 |
> |
24 |
> If it affects binaries, it needs to be a USE flag. |
25 |
|
26 |
So with your DEPEND="|| ( tetex ptex )" case, you're saying that it is valid |
27 |
because the choice of tetex or ptex doesn't affect the resultant binaries? |
28 |
Extrapolating that, specifying link dependencies within an || construct is |
29 |
flat out wrong? If so, it's way out of my domain so I can't really comment |
30 |
other than you haven't given a reason for this requirement. |
31 |
|
32 |
Having said that, I'll accept it if we're strictly talking in the EAPI-0 |
33 |
domain as there is no way for a package manager to guarantee a safe |
34 |
--depclean implmentation given that raw *DEPENDs are stored in the current |
35 |
installed package database. |
36 |
|
37 |
-- |
38 |
Jason Stubbs |
39 |
-- |
40 |
gentoo-dev@g.o mailing list |