1 |
2010-02-08 01:20:22 Brian Harring napisaĆ(a): |
2 |
> On Sun, Feb 07, 2010 at 12:17:17PM -0800, Zac Medico wrote: |
3 |
> > I noticed that this generates a depedency like "|| ( |
4 |
> > =dev-lang/python-2.7* =dev-lang/python-2.6* )" which is very similar |
5 |
> > to the way that QT3VERSIONS works in qt3.eclass. One thing that is |
6 |
> > sub-optimal about these types of dependencies is that you end up |
7 |
> > with lots of installed packages that have out-dated dependencies |
8 |
> > when the next minor version of python is released (python-2.8 in |
9 |
> > this case). In the case of the python dependencies, it might be more |
10 |
> > optimal to use a version range like ">=dev-lang/python-2.6 |
11 |
> > <dev-lang/python-3". |
12 |
> |
13 |
> Thing is, the first deps are valid- the deps you posted however |
14 |
> aren't and cannot be used as you're proposing. |
15 |
> |
16 |
> Under || ( dev-lang/python:2.7 dev-lang/python:2.6 ) |
17 |
> Having python:2.6 or python:2.7 merged satisfies it. |
18 |
> |
19 |
> Under >=dev-lang/python:2.6 <dev-lang/python:3.0 |
20 |
> having "|| ( python:2.6 python:2.7 )" satisfies it, as does |
21 |
> "|| ( python:2.4 python:2.5 ) || ( python:3.0 python:3.1 python:3.2 )" |
22 |
> |
23 |
> Literally, python:2.5 and python:3.1 merged would satisfy it, which is |
24 |
> completely contrary to the intent and an unlikely scenario (several of |
25 |
> my machines have such a deployment). |
26 |
|
27 |
I will improve handling of cases when minimal and maximal versions aren't |
28 |
specified. E.g. PYTHON_DEPEND="2" will be translated into dependency on |
29 |
"=dev-lang/python-2*". |
30 |
|
31 |
-- |
32 |
Arfrever Frehtes Taifersar Arahesis |