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