On Fri, 2 Dec 2011 13:21:55 +0100
todd rme
There are already some rough guidelines when dealing with python 3 packages, such as appending python3- to the beginning of the package name.
However, these guidelines, as far as I have seen do not deal with one important case. Many python packages currently put files in /usr/bin or /usr/share. These files usually have not identifier linking them to particular python versions, which means that the same files are installed by both python 2 and python 3 versions of the package. This leads to a conflict between python 2 and python 3 packages, one this does not seem to be properly addressed by current packages.
I see several solutions to this problem, all of which have benefits and drawbacks:
1. Add python version information to the beginning of the file name. For example, /usr/bin/sip becomes /usr/bin/python3-sip or /usr/bin/python3.2-sip. This has the benefit that it doesn't require any significant changes to current packaging. It has the disadvantage that anything looking for /usr/bin/sip will not find this file. Another disadvantage is that, as far as I have been able to find, python does not have a built-in way to do this, which would mean that the files have to be manually renamed. This is ugly and could potentially break things that are looking for specific file names, as well as making tab-completion on the command line less predictable. There is also a question of what would happen when python 2 support is ended, and a question of whether this would happen with python 3 packages or both python 2 and python 3 packages.
2. Add python version information at the end of the file name. So /usr/bin/sip becomes /usr/bin/sip-3 or /usr/bin/sip-3.2. This has similar issues to 1, but makes tab completion easier at the cost of making it unclear whether 3.2 is the version of sip or the version of python.
3. Create a new subdirectory in /usr/bin for python3 files. So for example /usr/bin/sip becomes /usr/bin/python3/sip or /usr/bin/python3.2/sip. This would require changing the path to include this directory. It has the advantage that the files in /usr/bin, which should be earlier in the path, should have priority. It also has the advantage that python has a built-in way to set what directory is used. It also means the file names will remain the same, so nothing will break. Python could also be patched to default to this directory so the install scriptlets would not need to be changed (although the files list scriptlets still would).
4. Create a new directory in %{python3_sitearch). So for example /usr/bin/sip becomes /usr/lib[64]/python3.2/bin/sip. This requires much more radical changes to how python files are handled, and it would be possible to have python2 files do the same. This has the advantage, however, of being more future-proof (i.e. python 4) and would allow multiple versions of the same python abi to be included (i.e. 3.2 and 3.3). Path priority issues could be solved by making sure /usr/lib[64]/python/bin is first in the path. This currently symlinks to /usr/lib[64]/python2, but simply by changing that /usr/lib[64]/python3 the python3 versions of the files would automatically become the defaults. It would also be easy for users to change by putting one ahead in their per-user path.
Personally I am leaning towards option 4. I think this is cleaner, more future-proof, and would make it easier to install multiple python versions in parallel (such as 3.2 and 3.3), but would be more work up-front. It is also a major change from the upstream defaults. However, only doing this with python3 packages not python2 ones would mean that it would mean only a handful of packages would need changes at this point, since there are only a few python3 packages. Other python3 packages could be set up this was when they are first created.
What are everyone elses' thoughts on this? It is probably a good idea to get this worked out before a major push to start getting python 3 versions of packages.
-Todd
Hi, this is quite interesting problem. I see that you think about it quite lot. I just miss two piece of information: 1) why someone beside developers want have installed binary for sip for python2 and python3? From user POV I want one binary that just works, ignoring if it is python 2 or 3. 2) Can you investigate how this issue solve in other distributions? It would be nice to have consistent solution and not reinvent wheel. Maybe some distribution have clean solution to it. Thanks Josef -- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger@suse.com SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org