[arch-dev-public] [arch-dev] Packaging inconsistencies of python modules

[Allan McRae]

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
>> repos.
>
> 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.

Allan