Packaging inconsistencies of python modules
On 07/04/11 02:17, Jan de Groot wrote:
On Wed, 2011-04-06 at 08:20 +1000, Allan McRae wrote:
I think the correct approach is the one that has been started:
python2-foo -> python-2.x package
python-foo -> python-3.x package
I am against using python3-foo instead of python-foo...
We just need to bite the bullet and get this entirely fixed in our
So naming scheme is more important than smooth upgrade paths? You can
fix everything in the repos, but you can't make a smooth upgrade path
without leaving lots of unused python3 libraries on systems where
python2-depending apps are installed.
With numpy, I chose the easy and smooth way, and that's the way of
adding provides and using python2 and python3 naming.
Consistent naming is more important to me. That way it is easy to find
the package you want. At the moment "pacman -S python-numpy" installs a
python2 version, which is inconsistent with (almost?) every other python
module providing python-2.x and python-3.x versions.
If this is all done in one go, then we can do a news announcement ad
advise that "pacman -Qqtd" will show the unnecessary packages.
As a sidenote, I think it will be very funny to see python4 getting
released in the future. Then we'll have to rename all python packages to
python3-* and name the new ones python-* again.
When discussing the policy for a /usr/bin/python2 symlink, there were
some comments from the main python developers that indicate this will
not be an issue for many, many, many years... But anyway, if python-4
does eventuate, we will know well in advance and can transition package
names properly using provides/replaces which would then be removed on
python-4 release. That ship sailed long ago for python-3.x.