Mailinglist Archive: opensuse-packaging (54 mails)

< Previous Next >
[opensuse-packaging] Re: python single-spec progress, questions
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.


< Previous Next >
List Navigation
References