Mailinglist Archive: opensuse-packaging (267 mails)

[todd rme <toddrme2178@xxxxxxxxx>]

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
-- 
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx