| 1 |
On Sun, Feb 07, 2010 at 12:17:17PM -0800, Zac Medico wrote: |
| 2 |
> I noticed that this generates a depedency like "|| ( |
| 3 |
> =dev-lang/python-2.7* =dev-lang/python-2.6* )" which is very similar |
| 4 |
> to the way that QT3VERSIONS works in qt3.eclass. One thing that is |
| 5 |
> sub-optimal about these types of dependencies is that you end up |
| 6 |
> with lots of installed packages that have out-dated dependencies |
| 7 |
> when the next minor version of python is released (python-2.8 in |
| 8 |
> this case). In the case of the python dependencies, it might be more |
| 9 |
> optimal to use a version range like ">=dev-lang/python-2.6 |
| 10 |
> <dev-lang/python-3". |
| 11 |
|
| 12 |
Thing is, the first deps are valid- the deps you posted however |
| 13 |
aren't and cannot be used as you're proposing. |
| 14 |
|
| 15 |
Under || ( dev-lang/python:2.7 dev-lang/python:2.6 ) |
| 16 |
Having python:2.6 or python:2.7 merged satisfies it. |
| 17 |
|
| 18 |
Under >=dev-lang/python:2.6 <dev-lang/python:3.0 |
| 19 |
having "|| ( python:2.6 python:2.7 )" satisfies it, as does |
| 20 |
"|| ( python:2.4 python:2.5 ) || ( python:3.0 python:3.1 python:3.2 )" |
| 21 |
|
| 22 |
Literally, python:2.5 and python:3.1 merged would satisfy it, which is |
| 23 |
completely contrary to the intent and an unlikely scenario (several of |
| 24 |
my machines have such a deployment). |
| 25 |
|
| 26 |
Ranged versions don't exist in any EAPI's currently although you *can* |
| 27 |
get away with them in the cases where the target has a single |
| 28 |
slotting- only in that case will the ranged versions from above work. |
| 29 |
Python obviously has multiple slottings, thus you cannot rely on it. |
| 30 |
|
| 31 |
If you want ranged versions, get them added to an EAPI- but do *not* |
| 32 |
introduce deps like you proposed into the tree since they're wrong |
| 33 |
(related, kindly fix the portage deps since I pointed this issue out |
| 34 |
several months back). |
| 35 |
|
| 36 |
~harring |
Archives