Am 10.01.22 um 01:55 schrieb Simon Lees:
On 1/9/22 21:53, Ben Greiner wrote:
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.
That is not the point. Tumbleweed gets the up to date packages from opensSUSE:Factory/standard soon enough. The point is that without :backports, the SLE/Leap repos in such a big project as d:l:p **partially** get up-to-date packages.
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.
Right now, you really don't know if you can take just that package or need to submit other packages from the same project along with it. I suggest disabling the" useforbuild" flag in the SLE/Leap repos for d:l:p then. After you wiped all existing binaries. If I understand the functionality of that flag correctly: From the User Guide:
useforbuild is used to control if a built result shall be copied to the build pool. This means it will get used for other builds in their build environment. When this is disabled, the build has no influence on builds of other packages using this repository. In case a previous build exists the old binaries will be used. Disabling this flag also means that "wipe" commands to remove binary files will have no effect on the build pool. Changing this flag does not trigger rebuilds, it just affects the next build. Default is enabled.
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.
...
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 am mostly concerned with the inability to use newer python-rpm-macros features like %pyunittest, %python_compileall and BuildRequires: %{python_module foo if %python-base < 3.10} because that will break the package build for those repos even if the source code itself would still work with 3.6. I opened boo#1187473 (upon request by the maintainer!) half a year ago, which was masked by the :backports usage, but comes to the surface again with the removal. Not to speak about all those cases where this caused problems in other projects. - Ben