[arch-dev-public] [arch-dev] Packaging inconsistencies of python modules
allan at archlinux.org
Thu Apr 7 07:19:20 EDT 2011
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.
More information about the arch-dev-public