Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 525052 - sys-apps/portage-2.2.8-r2 should depend on slotted atoms for dev-lang/python
Summary: sys-apps/portage-2.2.8-r2 should depend on slotted atoms for dev-lang/python
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-11 13:37 UTC by Gino McCarty
Modified: 2022-07-28 04:49 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gino McCarty 2014-10-11 13:37:53 UTC
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
Comment 1 Mike Gilbert gentoo-dev 2014-10-11 13:54:39 UTC
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.
Comment 2 Zac Medico gentoo-dev 2014-10-11 18:40:37 UTC
(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
Comment 3 Gino McCarty 2014-10-12 03:09:30 UTC
(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
Comment 4 Zac Medico gentoo-dev 2014-10-12 03:46:57 UTC
(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.
Comment 5 Brian Dolbec gentoo-dev 2014-10-12 03:58:50 UTC
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.
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-28 04:49:01 UTC
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.