Considering all of the talk about improving openSUSE quality, and with
12.2 branched, I would like to discuss somewhat how to move forward
with Python packaging in openSUSE.
There are three big things happening right now with Python for openSUSE.
First, and most prominently, is Python 3. Python 3 has been
supported on openSUSE since at the latest 11.4. However, Python 2.x
still remains the default, but it will no longer be getting upstream
updates. At the present time I don't see that being quite ready to
change, since some critical packages (like django, wxpython, and
matplotlib) are still Python 2-only. Unless all of those, and
probably some others, support Python 3 by the next openSUSE release, I
don't think switching will work. We probably need a list of packages
that need python 3 support before we switch to python 3 by default.
That doesn't mean Python 3 doesn't matter. I and several others
have been working to get Python 3 support for most critical Python
packages available for openSUSE 12.2. I think we have largely
succeeded. For the next openSUSE release, I think we should have a
policy that, if a new python package is submitted that has upstream
Python 3 support, it must be submitted with both Python 2 and Python 3
versions of the package. There might even be a policy that any
packaging of a new version of a python package that supports Python 3
should also have the Python 3 version packaged, but that may be going
too far.
Further, I think we should have an embargo on any new Python
packages that do not have Python 3 versions and don't appear to have
been updated within the last couple of years, since it is unlikely
such packages would ever get a Python 3 version. Of course exceptions
can be made on a case-by-case basis, for instance if the package is a
dependency of an important Python package. In the end I don't think
we really want unmaintained software to begin with, but this is all
the more serious when it is unmaintained software that depends on
deprecated, unmaintained software.
There is an issue that some Python packages install non-versions
software, such as in /usr/bin. This makes installing Python 2 and 3
versions in parallel difficult. For the next openSUSE release I
intend to implement update-alternatives for these files, so users can
easily switch between running Python 2 and Python 3 versions. This
also solves some issues where Python 3 versions of packages depend on
the Python 2 versions.
I know there is a Python Package Index Reader that scans pypi for
updated packages. I don't know how it works myself, but is there a
way to also scan to see if the package supports Python 3? They should
have one or more of the following categories: "Programming Language ::
Python :: 3", "Programming Language :: Python :: 3.0", "Programming
Language :: Python :: 3.1", "Programming Language :: Python :: 3.2",
or "Programming Language :: Python :: 3.3". Sending regular email
alerts about such packages that do not yet have Python 3 versions
would be nice.
Also, currently most Python 3 packages that use the same tarballs
as the Python 2 versions have the Python 3 version link to the Python
2 version, which has Python 2 and Python 3 spec files. I would like
to turn this around for the next openSUSE release, so the Python 2
version links to the Python 3 version and the Python 3 version is the
official factory devel package.
The point of all of this is to ease the transition to having
Python 3 as the default easier, which I expect will likely will happen
wit2 release after 12.2, judging by the rate of progress of upstream
Python 3 porting. Basically most or all of the tasks that are needed
before we would be ready to switch the default Python version should
be done for the next openSUSE release.
There are 3 other issues, which are more openSUSE-specific.
First is the new python autodeps system, which should allow the
requires of Python 2 and 3 packages to be automatically detected.
This will make packaging python easier and installing python packages
more reliable. It still needs testing. I suggest a tiered approach:
first, which I am doing now, I am testing it against all the python
packages in devel:languages:python3. If that seems to work, I will
then switch to implementing it directly in devel:languages:python3.
If that works, I also implement it in devel:languages:python. If that
works, it can be implemented globally (at least for Factory build
targets).
The second is --record-rpm. This allows python to automatically
list files that are then used by rpm file lists. As far as I
understand this is an openSUSE-specific hack whose use is now
discouraged. It also leads to some problems, especially if the
upstream package name changed. If this understanding is correct, I
think this should be officially deprecated, with a plan to remove it
for 2 releases after 12.2. For the release after 12.2, I think it
should go through a few stages. First, add an rpmlint warning about
the use of this build option. After a couple months, upgrade the
badness of this warning so it causes an automatic package failure. A
few months after that, change the warning to an error. No packages in
Factory should use the option.
Finally, there is the use of the common %{python_sitelib}/* and
%{python_sitearch}/* items in the rpm files list. These have been
used a lot because they make packaging easier. However, they have the
disadvantage, in my opinion, that there can be (and are) major changes
in the upstream package, even complete name changes, that go
undetected because these commands essentially match every possible
python file. I think we should discourage this in the wiki, reject
new packages that use it, and add an rpmlint warning for it, with the
goal of removing this entirely from the next openSUSE release.
So does anyone have opinions on these proposals? I know this is a big
wall of text, so I can break it up into individual messages with
different issues you think that would simplify reading or discussion.
-Todd
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org