On Tue, Nov 1, 2016 at 5:19 PM, Todd Rme
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.
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.
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 ;) )
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).
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.
Agreed.
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 number), and 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) gmsh mongodb openblas petsc tetgen 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 hdf netcdf-cxx qwt fundamental packages with a high chance of breakage: GeoIP agg cmake doxygen freeimage lapack libgit2 libsmi lz4 mercurial opencv-qt5 openpgm snappy vtk vtkdata xrootd zeromq swig3 - this has be renamed to just "swig", packages shouldn't use it anymore low-risk packages that can be copied if needed cfitsio fftw3 geos hdf5 hdf5-1_8 libcryptopp libsodium netcdf netcdf-cxx4 parallel-netcdf portmidi qhull qscintilla qscintilla-qt5 suitesparse used only by python packages, should be owned by d:l:p blosc DSDP should by be in a subject-specific repo (moved in necessary) gccxml liblouis libsvm meep pythonocc rrdtool sundials python/3-PyAVM python/3-pyMinuit2 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@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org