On Saturday, June 29, 2019 10:18:36 AM CEST Tomas Chvatal wrote:
It would certainly make my life a whole lot easier, as singlespec is difficult (pulls in a lot of python 2.x stuff) and makes collaboration with fedora less feasible.
NO. We need singlespec as long as we plan to support older codestreams.
What do you mean by older codestreams? sle12? or sle15? singlespec only works with sle12sp3 or newer, "older codestreams" are not having the right macros and the right version of macros. even sp3 is very painful.
In the end it was easier to maintain non-singlespec packages for sle12. For sle15 this might be true though most packages I've seen as singlespec did not actually work in python 2.x only mode (or in 3.x only mode in some cases, although things were generally better there).
That being said we made the unfortunate choice to use singlespec for the packaging CI, and there we're now switching to python 3 only, so singlespec only makes problems doesn't solve any (most recent breaking everything example is the rename of python-Sphinx to python-Sphinx1 ).
And esp. since you guys backport a lot of stuff to older distributions it would make sense.
I'm afraid that is no longer relevant with the shift of focus to sle15 where python 3.6 is available (which is good enough for most dependencies) and the only elligible python anyway in less than 6 months from now.
Also we planned to allow people using the pypy with singlespec which should make some science people really happy.
Do they need all 1000+ packages as pypy versions? How likely is it that they all work with pypy? I would be curious to see an experiement on this.
For us it means we will be more generous in writting '%define skip_python2 1' and simply not bother about its support if it is no longer feasible.
Yep, which makes the python 2.x compatible package disappear, breaking every singlespec package that depends on it. Exactly these generous "skip_python2" settings that get checked into tumbleweed are causing most of the problems right now.