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. 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. 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. 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. - Ben * @Adrian: Why does the web interface not include :Update?
Am 09.01.22 um 12:23 schrieb Ben Greiner:
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.
Sorry: boo#1187473 https://bugzilla.opensuse.org/show_bug.cgi?id=1187473
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
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
On 1/10/22 20:40, Ben Greiner wrote:
On 1/9/22 21:53, Ben Greiner wrote: 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
Am 10.01.22 um 01:55 schrieb Simon Lees: 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.
In the past we have shipped similar updates to rpm-macros into the Update repo and not released them to customers then with the updates repo enabled they can still be used for builds. That is probably the best solution to this problem or we update the wiki to indicate these features don't exist in 15.3. -- 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
Am 10.01.22 um 11:19 schrieb Simon Lees:
On 1/10/22 20:40, Ben Greiner wrote:
On 1/9/22 21:53, Ben Greiner wrote: 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
Am 10.01.22 um 01:55 schrieb Simon Lees: 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. In the past we have shipped similar updates to rpm-macros into the Update repo and not released them to customers then with the updates repo enabled they can still be used for builds. That is probably the best solution to this problem or we update the wiki to indicate these features don't exist in 15.3.
I'm okay with that. Don't forget the necessary prjconf definitions, which you need to wrap into %if conditions now that they are not inherited from a non-TW repo anymore:
%if "%_repository" == "15.3" || "%_repository" == "15.4" Macros: ## PYTHON MACROS BEGIN # adapted form of https://github.com/openSUSE/python-rpm-macros/blob/master/default-prjconf for SLE/Leap # requires python-rpm-macros >= 20210204 # order of %pythons is important: The last flavor overrides any operation on conflicting files and definitions during expansions, # making it the "default" in many cases --> keep the primary python3 provider at the end. %pythons %{?!skip_python2:python2} %{?!skip_python3:python3} %add_python() %{expand:%%define pythons %1 %pythons}
# This method for generating python_modules gets too deep to expand for rpm at about 5 python flavors. # Hence, python_module_iter is replaced by python_module_lua in macros.lua. # However, OBS cannot expand lua, but has a much higher expansion depth, so this works fine for the server side resolver. %python_module_iter(a:) %{expand:%%define python %{-a*}} ( %python-%args ) %{expand:%%{?!python_module_iter_%1:%%{python_module_iter -a%*}}%%{?python_module_iter_%1}} # pseudo-undefine for obs: reset for the next expansion within the next call of python_module %python_module_iter_STOP %global python %%%%python %python_module() %{?!python_module_lua:%{expand:%%define args %{**}} %{expand:%%{python_module_iter -a %{pythons} STOP}}}%{?python_module_lua:%python_module_lua %{**}} ## PYTHON MACROS END :Macros %endif
- Ben
participants (2)
-
Ben Greiner -
Simon Lees