On 1/9/22 21:53, Ben Greiner wrote:
Am 09.01.22 um 05:13 schrieb Simon Lees:
The crucial part is the
<path project="devel:languages:python:backports" repository="15.3"/>
which is still missing in devel:languages:python. Why should we put backports into regular devel project? I thought that
Dne 08. 01. 22 v 13:03 Ben Greiner napsal(a): point of 15.3 repository in d:l:p is to show what is buildable on the regular real Leap 15.3. The real main purpose was Leap users used to add d:l:p to there systems which would cause them to break in strange ways because it would always
On 1/9/22 09:53, Matěj Cepl wrote: pull in packages that wouldn't work on there system.
So Leap builds were disabled in d:l:p and backports was created just to have modules built against the actual python in leap so users could get the newer versions of the modules that would work with the distro python which generally breaks less things.
In neither the use case you or I described is there a need for d:l:p to include d:l:p:backports so I also don't understand the use case, so what exactly is broken and how does this change fix it. On the other hand not having the Update target in 15.3 can cause issues. I'd use the following for example.
<repository name="openSUSE_Backports_SLE-15-SP3"> <path project="openSUSE:Backports:SLE-15-SP3:Update" repository="standard"/> <path project="openSUSE:Backports:SLE-15-SP3" repository="standard"/> <arch>x86_64</arch> </repository>
Starting at the point in time before the user's request started to break everything, the question is rather, "why should we remove backports from the regular devel project"?
Look at the "SLE_15_SP2". That's the state 15.3 also had before the breakage. Remember the mentioned "deleted" entries, which you removed in the meantime.
If you want to change policy and remove :backports these are some consequences, visible in the current state:
1. All the packages directly in d:l:p use the current development state, meant for Factory. 2. All packages outside of d:l:p, even those in d:l:p:numeric and most importantly d:l:p:Factory are not considered.
For the Tumbleweed repo considering d:l:p:factory might make sense depending on how you sort out stagings and whether you want to use use a staging or d:l:p to work out what an update to python breaks at a guess using a staging is less disruptive though.
3. Because of 2. python-rpm-macros is back at the old version from plain 15.3, which does not support newer features such as python_compile or support for rewriting runtime rich boolean rpm dependencies. Reopen boo#1887474.
Well as a SLE / Leap maintainer (with the updates repo added) this really actually tells me what I want to know, which is could I take this package as is and send it to Leap as is or am I better updating the Leap version. There's already a backports repo to tell me does this work with everything at its newest.
4. The obs resolver cannot interpret the rich boolean dependencies using the '%python' syntax in BuildRequires, because the prjconf from :backports is not inherited.
The mix of 1. and 2. makes the SLE/Leap repositories in d:l:p totally useless. 3. and 4. means that all specfiles using those features fail for SLE/Leap.
It depends on what you define as "useful", certainly 15.3 and 15.4 shouldn't be publishing results as they are now because that was the whole point of having backports. But I would say they are still useful in that they tell us what does and doesn't work and if we know that a package no longer works and are ok with it we can always disable building for that package.
With all the "Python 3.6 is EOL" and "We don't want to support packages for both 3.6 and 3.10 at the same time", maybe it is better to just disable all SLE and Leap repositories in d:l:p*. Devel projects outside of those namespace can use plain 15.3 or *:Update and see if it works with the system shipped packages. If not, they have to maintain their own set of backported packages compatible with each other. Sorry, Axel.
I suspect there will still be a number of packages that still work with 3.6 and 3.10, many off the smaller libraries don't change that much so I still think it will provide useful information. I'm not really sure what Axel is trying to do so its hard to comment much on that other then users generally just have plain 15.3 so thats what we should always target and also users should never install or use d:l:P it simply breaks stuff too often. This is why we have backports, but from the sounds of it, it is likely the safest option to just create an additional repo and link in the packages you actually need, then the system only changes by the amount required and you don't end up with a large number of packages swapping repos when they don't need to causing further issues down the track. (The exception being if you need newer system level stuff because that will have a high chance of breaking anyway).
* @Adrian: Why does the web interface not include :Update?
The Update repo is not really useful on its own unless its paired with the general release repo, probably what the web interface should have though is an option to create "15.3" and "15.4" thats setup to contain both. Although the other issue there is 15.4 might not have an update repo yet so everyone would have to change sometime after its created. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B