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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org