On Mon, Oct 31, 2016 at 11:28 AM, jan matejek
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.
Fair enough, but I still think keeping things consistent would be
preferable. So even if there is no "pypy2" commands, I think we
should still call iot "pypy3" to maintain the same pattern.
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 ;)
We are getting about 1 python minor version a year, with 3.6 coming
out any time now. Guido has said he that python 4 will just be python
3.10 because he doesn't like double-digit versions. This means we are
probably about 4 years away from Python 4. So I would include the
python 4 transition in any plans we make, it isn't far off at all. In
fact it will probably happen about the same time as 2.7 is EOL.
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 ;) )
Agreed. My point is that we need to be very clear about this policy.
The current python application naming policy is pretty fuzzy and I
don't think it handles these "edge" cases well (scare quotes because
they are by far the most common case).
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.
Although IDEs are a problem because the python shell they support is
usually the same as they python version they were built against.
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.
What about, say, a general-purpose numerical library that needs some C
library to do some task?
What about an update to a key existing program that gets a new
indirect C dependency?
I don't think a blanket ban on non-python packages will work. I think
we need to look at how the packages are used and what needs them on a
case-by-case basis. I think there are a variety of scenarios that
need different approaches.
The first is that the package is unused by anything, or where the
version currently available from the openSUSE version is sufficient.
Of course this should be deleted outright (after a one-week warning
period if they aren't linked to somewhere else).
The second is that a package is so fundamental that using newer
versions than the openSUSE version was built against has a high chance
of breakage. These packages should never be allowed.
The third is that a package is niche, but the python package depends
on an executable. These packages should alo never be allowed.
The fourth are niche packages used by only bindings for a niche python
package, or are extremely subject-specific. These should be moved to
the appropriate repository along with their python bindings. If the
library is in Factory the bindings can be linked, but only where newer
versions of the library is not needed.
The fifth packages with a low chance of conflicts whose library is
required by very important python packages. In cases where a newer
version is needed, these should have a minimal version copied (not
linked) into d:l:p, have the -devel package be renamed from
"foo-devel" to "foo-sonum-devel" (where "sonum" is the so
have the OSC package name renamed from "foo" to "foo-sonom-osver"
(where osver is the openSUSE version).
The last are libraries that are essentially only used by python
packages that are not part of the original package. These are very
rare. They should be owned by d:l:p.
Here is the list of non-python packages along with my assessment of
whether they should stay or go. I won't distinguish between d:l:p and
d:l:p3 because it won't matter soon. These are all highly debatable
(except probably the unused ones, although I may have made mistakes
with them), this is just my own opinion. Also, note that I am not
addressing python-based applications here, that is a separate issue.
apparently unused (or a dependency of an apparently unused package)
cgns - apparently used only by gmsh
blacs - apparently used only by petsc
hypre - apparently used only by petsc
scalapack - apparently used only by petsc
newer version not useful
fundamental packages with a high chance of breakage:
swig3 - this has be renamed to just "swig", packages shouldn't use it
low-risk packages that can be copied if needed
used only by python packages, should be owned by d:l:p
should by be in a subject-specific repo (moved in necessary)
mhash - used by meep
harminv - used by meep
libctl - used by meep
oce - used by pythonocc
geom - used by pythonocc
smesh - used by pythonocc
erfa - used by python/3-PyAVM
wcslib - used by python/3-PyAVM
python/3-meep - bindings for meep
python/3-py-rrdtool - bindings for rrdtool
python/3-pygccxml - bindings for gccxml
python/3-pysundials - bindings for sundials
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org