Re: [opensuse-packaging] Re: python single-spec progress, questions

On 11/03/2016 06:38 AM, Todd Rme wrote:

On Mon, Oct 31, 2016 at 11:28 AM, jan matejek wrote:

...

hello,

On 27.10.2016 20:35, Todd Rme wrote:

...

2. Along those lines, I think pypy2 and pyp3 versions should be available, especially with a lot of progress now happening in pypy3 thanks to mozilla funding it.

I would very much prefer to NOT support pypy 2 at all, now that pypy3 is making significant progress. Given that we don't really support pypy2 at this point, I don't see any benefits in starting. That's why my proposal uses unversioned "pypy". That is not going to be future-proof if we ever get pypy 4, but, well, I say we take that risk ;)

...

I would personally keep dlp as a generic place for all python packages. This has worked very well up to this point and I don't see any advantage to changing it.

I have always considered d:l:py to be a generic place for Python modules and tools -- that is, for software where Python is a fundamental property, as opposed to implementation detail. From your conversation with Simon, it doesn't seem like you disagree on this, but you're concerned about the "edge case" packages -- where it's unclear whether the "library" or the "utility" part is more important.

Let me clarify that I don't propose to throw these out summarily. I'm more concerned about the actually-clear-cut apps. I don't know how many of those are in d:l:py now, but I have rejected several in the last year, and I'd like to make it clearer that these don't belong. (Also, being more careful about the edge cases would not hurt, IMHO ;) )

...

I think the rule should be that if the executable is intended for use with python files or packages, it should provide both python 2 and python 3 versions when available.

to this I would add, "and if the executable doesn't natively support multiple python versions". For instance, if pylint3 could work on python 2 by itself, I would include it in the rule and say that we will only distribute pylint3. This could very well be the case for IDEs and similar.

...

...

Finally, three, d:l:py is collecting non-python dependencies of python modules. That should not be happening. Analogously to point one, policy proposal: If your package depends on something that is not appropriate for d:l:py, either get that dependency into Factory, or your package is also not appropriate for d:l:py.

A lot of these are backports for older versions of openSUSE that either have outdated versions of the library or lack the library entirely. So yes, I agree if it really has non-Factory dependencies it probably shouldn't be there. But I think the bigger problem is that many of these are (or were) needed but are building for openSUSE

It doesn't make sense to me to build a binding for, say, 13.2, for a library that is not present or too old in 13.2. In such case, I think the right solution is to disable build for the older SUSE version -- and optionally link the binding to a project that provides the newer library for the older distribution.

...

1. The layout of the repositories. With single spec files, does "devel:languages:python3" even make sense anymore? I think we should phase it out.

Definitely. That is one of the goals.

...

2. Package naming. Might this be a chance to switch from using python-foo to python2-foo? Either way, I would strongly suggest pypy packages using pypy2-foo and pypy3-foo from the beginning, rather than pypy-foo.

Probably not, for technical reasons. The problem is that the macroset can't modify what's already explicitly written in the spec file. So if the spec is for python-foo, and has a %files section, then we MUST build package python-foo that includes the files listed.

We could of course rename the package and spec, but, as Christian pointed out, that is a lot of renames for no clear benefit.

What makes more sense is to gradually rename packages to python3-foo, and generate python2-foo subpackages (with Provides: python-foo, which could in time move to the python3 subpackage). The macroset is designed with this possibility in mind, although it's probably buggy at the moment.

(as for pypy, as I wrote before, i would prefer to never even use versioned names for it)

...

3. Version-specific packages. There are still a lot of packages that only support python 2, and an increasing number that only support python 3. Should these use the macros or be kept simple?

python2-only, I would consider legacy and keep simple, until such a time when they move to python 3

python3-only, I'd use the macros and "%define have_python2 0". After all, these could work on pypy or other flavors that might be created in the future.

...

4. Repository cleanup. There are packages that haven't been updated in many years and are not under active development. Who knows what sort of security or compatibility issues they might have. It might be worthwhile to move them to a separate repository (perhaps d:l:p:archive or d:l:p:legacy) with lower build priority, or delete them outright, to free up resources for packages that are better-maintained. 5. Disabled packages. Packages that are completely disabled should almost certainly be deleted.

good ideas

regards m.

Another issue: might this be a good time to drop support for SLES 11.4? It is the only version that doesn't support python 3, and many packages require some significant workaround to keep building. I think it is probably past due to drop support for it, or at least to disable all builds and freeze the repo.

As general info SLED is out of support and SLES will have General support until 31 Mar 2019 and LTSS support until 31 Mar 2022 which is still quite some time. I don't have a strong opinion here but dropping it seems reasonable to me unless people indicate they are using it and are willing to do the work. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B