Snip from `emerge -cav python:3.4` dev-lang/python-3.4.1 pulled in by: sys-apps/portage-2.2.8-r2 requires =dev-lang/python-3*[ssl] portage does NOT actually depend on python3.4.x (yet) Should actually depend upon the version of python it is actually using which is at this time python-2.7 and python-3.3 the following line in the ebuild file python_dep_ssl="python3? ( =dev-lang/python-3*[ssl] ) should be python_dep_ssl="python3? ( || ( =dev-lang/python-3.3[ssl] =dev-lang/python-3.4[ssl] ) ) Reproducible: Always
I believe this has already been fixed in newer versions of the ebuild by removing the python2 and python3 use flags. However, with python:3.4 having just been stabilized on amd64, it is likely users will be running into this.
(In reply to Harvey Mittens from comment #0) > Snip from `emerge -cav python:3.4` > > dev-lang/python-3.4.1 pulled in by: > sys-apps/portage-2.2.8-r2 requires =dev-lang/python-3*[ssl] > > > portage does NOT actually depend on python3.4.x (yet) > > Should actually depend upon the version of python it is actually using > which is at this time python-2.7 and python-3.3 If you enabled the python3 USE flag, then python-2.7 does not suffice, since the ebuild hardcodes the shebangs for python3. The dependency actually works properly, since =dev-lang/python-3*[ssl] matches all supported versions of python3. The reason that it pulled in python3.4 is that it was recently stabilized, as noted in comment #1. > the following line in the ebuild file > > python_dep_ssl="python3? ( =dev-lang/python-3*[ssl] ) > > should be > > python_dep_ssl="python3? ( || ( =dev-lang/python-3.3[ssl] > =dev-lang/python-3.4[ssl] ) ) What about python3.2? It will suffice, and is also matched by the =dev-lang/python-3*[ssl] atom. So, the existing dep appears to be fine (though portage-2.2.14_rc1 now uses slotted deps generated by the distutils-r1 eclass, as noted in comment #1). If you don't want python3.4 to be pulled in, then you should simply mask it like this: echo "dev-lang/python:3.4" >> /etc/portage/package.mask
(In reply to Zac Medico from comment #2) > (In reply to Harvey Mittens from comment #0) > > Snip from `emerge -cav python:3.4` > > > > dev-lang/python-3.4.1 pulled in by: > > sys-apps/portage-2.2.8-r2 requires =dev-lang/python-3*[ssl] > > > > > > portage does NOT actually depend on python3.4.x (yet) > > > > Should actually depend upon the version of python it is actually using > > which is at this time python-2.7 and python-3.3 > > If you enabled the python3 USE flag, then python-2.7 does not suffice, since > the ebuild hardcodes the shebangs for python3. This logic seems circular here, this is the issue I am filing the bug about > The dependency actually works properly, since =dev-lang/python-3*[ssl] > matches all supported versions of python3. The reason that it pulled in > python3.4 is that it was recently stabilized, as noted in comment #1. > > > the following line in the ebuild file > > > > python_dep_ssl="python3? ( =dev-lang/python-3*[ssl] ) > > > > should be > > > > python_dep_ssl="python3? ( || ( =dev-lang/python-3.3[ssl] > > =dev-lang/python-3.4[ssl] ) ) > > What about python3.2? It will suffice, and is also matched by the > =dev-lang/python-3*[ssl] atom. So, the existing dep appears to be fine > (though portage-2.2.14_rc1 now uses slotted deps generated by the > distutils-r1 eclass, as noted in comment #1). > > If you don't want python3.4 to be pulled in, then you should simply mask it > like this: > > echo "dev-lang/python:3.4" >> /etc/portage/package.mask I am aware of masking, it however seems unecessary, as a simple change to the ebuild code would resolve this issue, The fact of the matter remains here, python 3.4 is pulled in by a package which does not actually use python 3.4 your argument in justfications of sheband matching does not resolve this issue.. however slotting does, but in the mean time all users (of portage)(of gentoo for that matter) will pull python-3.4 regardless of its need or use. my suggestion of || () to resolve the issue is a direct duplicate of the same behavior already in use in your current ebuild for the python2.7 vs 2.6 ssl dependency
(In reply to Harvey Mittens from comment #3) > I am aware of masking, it however seems unecessary, as a simple change to > the ebuild code would resolve this issue, Do you not use the --update option as a means to avoid updates (see bug 275945 and bug 478188)? Otherwise, masking is the only reliable way that portage has to avoid pulling in new package slots. If --update doesn't cause emerge to pull in new slots, then that's a bug.
This older version of portage should run on python-3.4 without problem. I'll do some tests to make sure. Then I'll add that target to the ebuild. As for re-doing things... I'm not keen on it, portage has had a number of changes and the new code should hopefully be stabilized soon. That will allow some of this older code/ebuild to be phased out.
Portage has long used the correct eclasses. For python-any-r1, an issue like this might arguably still exist (bug 702806), but Portage certainly doesn't use that.
