Dirk Mueller píše v Čt 04. 07. 2019 v 15:55 +0200:
On Saturday, June 29, 2019 10:18:36 AM CEST Tomas Chvatal wrote:
Hi Tomas,
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.
All the macros were synced by me to the latest python-rpm-macros and were released properly in IBS. You can use them all quite fine if you build against the :Update and not against :GA.
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).
I synced this couple of months ago when I noticed it was not synced, because I thought you guys did it whenever more stuff was added to Cloud modules. We would've done it even before if you told us. So now on IBS the macros are at the latest version in SLE12:Update and all codestreams are able to work with it.
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 ).
So your CI is picking just selective packages or what is the issue? The Sphinx1 i didn't call as python2-Sphinx because I expected you guys to enable the python3 again because you would still need it, as last upgrade of Sphinx it was reverted few times to get you to migrate). The same rationale I am now doing with the pytest (adding pytest3 and pytest4) because some software still needs the pytest3 on python3...
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.
We still happen to have bunch of SLE12 requests
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.
Quite big load of them really work (some need minor tweaks in build commands), we just didn't have time to enable it. When singlespec was created it was with this in mind actually, because we knew that the python2 will hopefully die quickly.
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.
Hmm this can cause trouble for you, but they stay resolvable for TW so how can we change this. Because we are not dropping any stuff when we do the skip python, with the naming I always add another package that provides the older version that still provides python2 and everything stays resolvable on TW. Should we email somewhere to notify you guys about new deps? Or can we tag it somewhere? Cheers Tom