devel:languages:python:backports and enabled repositories
Hello, Unfortunately, many builds for SLE and Leap in devel projects are currently broken. This is a result from some back and forth changes of enabled repositories in devel:languages:python:backports, which needs to be corrected in a consistent way.* Some history: devel:languages:python:backports had several repositories for the SLE/Leap 15 family enabled: - SLE_15 - SLE_15_SP1 - SLE_15_SP2 - SLE_15_SP3 - openSUSE_Leap_15.2 - openSUSE_Leap_15.3 - (openSUSE_Leap_15.4, not sure if this ever existed) - 15.3 - 15.4 Because of the unification between SLE and Leap from 15.3 onwards, some of these are identical duplicates but create the duplicate workload for the obs servers (all of Factory in this case!). So some time ago, there was a survey and poll how newly enabled projects should name their single SLE15SP3/Leap_15.3 repositories, and the decision was "15.3". I can't find the reference right now. Unfortunately there is no guideline or wiki page about it, only some mailinglist post. There was also a discussion on the packaging ML earlier last month, without a clear guideline. As a consequence, the web interface only lets you create one "15.3" repository, no matter on which distribution checkmark of the SLE/Leap family you click: <repository name="15.3"> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> Now, devel:languages:python, some of the subprojects there and possible other devel projects outside of this namespace had devel:languages:python:backports in their path like this: <repository name="15.3"> <path project="devel:languages:python:backports" repository="TARGETREPO"/> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> Unfortunately, among projects, TARGETREPO was not used consistently as "15.3" but used a variant of the duplicates above. Enter some user** who wanted to get "his" project fixed. His request: "Please delete the duplicates, please use openSUSE_Leap_15.3 as the proper name." His request was granted by the project maintainer. Unfortunately, this broke all the devel projects which used one of the deleted repositories 15.3, including devel:languages:python. The meta configuration now read: <repository name="15.3"> <path project="deleted" repository="deleted" /> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> Now, just re-adding 15.3 does not fix the "deleted" entries. You have to fix it manually. So my request to fix the path entries and use the repo names found by consensus was understood as to revert the previous users' request and recreate the "15.3" and "15.4" repositories in d:l:p:backports. On the other hand, openSUSE_Leap_15.3 and similar have been removed again (as they would indeed be duplicates). Now of course those projects having had those repositories in their path also have the "deleted" entries, while those from the previous deleted still have it too. In order to fix things and get consistent, I propose that all maintainers of devel projects making use of devel:languages:python:backports, devel:languages:python and any transitive projects check their repository configuration and adjust accordingly. In my eyes, the correct entries would be for all of them: <repository name="15.3"> <path project="devel:languages:python:backports" repository="15.3"/> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="15.4"> <path project="devel:languages:python:backports" repository="15.4"/> <path project="openSUSE:Leap:15.4" repository="standard"/> <arch>x86_64</arch> </repository> - Ben [1] https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/thread... * Although the value of d:l:p:backports is vanishing fast anyway. Most packages in Factory have already dropped or will drop soon support for Python 3.6. ** name intentionally omitted, this is not a blame post but a request to get the technical situation corrected.
Hello Ben, Am Freitag, 7. Januar 2022, 15:14:45 CET schrieb Ben Greiner: ....
In order to fix things and get consistent, I propose that all maintainers of devel projects making use of devel:languages:python:backports, devel:languages:python and any transitive projects check their repository configuration and adjust accordingly. In my eyes, the correct entries would be for all of them:
<repository name="15.3"> <path project="devel:languages:python:backports" repository="15.3"/> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="15.4"> <path project="devel:languages:python:backports" repository="15.4"/> <path project="openSUSE:Leap:15.4" repository="standard"/> <arch>x86_64</arch> </repository>
I can only speak for the 15.3 repo, which looks same as I had it (working!) last time, but now, after the recent change, has many unresolvables, mainly due to outdated versons of programs, which are now offered by the 15.3 setup. It did not help to use <path project="openSUSE:Leap:15.3:Update" repository="standard"/> instead. What is your proposal to fix this? Cheers Axel PS: I guess the dust should have settled, means the 15.3 build changes on OBS are complete. So I do not expect a positive 'miracle' from this
Am Samstag, 8. Januar 2022, 13:03:01 CET schrieb Ben Greiner:
Am 08.01.22 um 12:28 schrieb Axel Braun:
..
What is your proposal to fix this?
The crucial part is the
<path project="devel:languages:python:backports" repository="15.3"/>
which is still missing in devel:languages:python.
Is there a functional reason why this got not updated, or has it 'just to be done'? Thx Axel
Dne 08. 01. 22 v 13:03 Ben Greiner napsal(a):
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 point of 15.3 repository in d:l:p is to show what is buildable on the regular real Leap 15.3. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 How many Bavarian Illuminati does it take to screw in a light bulb? Three: one to screw it in, and one to confuse the issue.
On 1/9/22 09:53, Matěj Cepl wrote:
Dne 08. 01. 22 v 13:03 Ben Greiner napsal(a):
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 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 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> -- 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 Sonntag, 9. Januar 2022, 05:13:14 CET schrieb Simon Lees:
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>
I tried different setups, but I always end up with unresolveables. Looks like the Leap 15.3 setup was fixed to death (kaputt repariert as we say in DE) I have opened https://bugzilla.opensuse.org/show_bug.cgi?id=1194422 for this Cheers Axel
Am 09.01.22 um 05:13 schrieb Simon Lees:
On 1/9/22 09:53, Matěj Cepl wrote:
Dne 08. 01. 22 v 13:03 Ben Greiner napsal(a):
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 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 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:
On 1/9/22 09:53, Matěj Cepl wrote:
Dne 08. 01. 22 v 13:03 Ben Greiner napsal(a):
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 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 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:
Am 10.01.22 um 01:55 schrieb Simon Lees:
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 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:
Am 10.01.22 um 01:55 schrieb Simon Lees:
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 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
Dne 09. 01. 22 v 5:13 Simon Lees napsal(a):
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 pull in packages that wouldn't work on there system.
That's the purpose I emphatically do not want to support. Devel projects are devel projects because they are for development of packages for Factory. That's it. If you want to have something to download from, make your own specific project in OBS. d:l:p:backports was used as a concession to Cloud package maintainers who wanted to have all python-related packages from Factory in one project, it was never meant for normal use, and it is very emphatically NOT maintained by the Python team aside from running https://github.com/openSUSE/python-backports-generate/blob/master/backports_... from time to time. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 One reason that life is complex is that it has a real part and an imaginary part. -- Andrew König
On Sonntag, 9. Januar 2022, 23:09:29 CET Matěj Cepl wrote:
Dne 09. 01. 22 v 5:13 Simon Lees napsal(a):
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 pull in packages that wouldn't work on there system.
That's the purpose I emphatically do not want to support. Devel projects are devel projects because they are for development of packages for Factory. That's it.
erm, no, not in such general way. We used to have them always as devel area for factory, but got also testing from the users of stable distributions. IIRC only the python folks decided to split factory and leap builds into two seperate projects, dunno why.
If you want to have something to download from, make your own specific project in OBS.
Please do not be so generic here. At least in all of the projects I work it is always the same project. And a split would be a not wanted burden to deal with multiple places. I do not say that the python way is invalid, but it is definitive not the standard. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
On 1/10/22 17:13, Adrian Schröter wrote:
On Sonntag, 9. Januar 2022, 23:09:29 CET Matěj Cepl wrote:
Dne 09. 01. 22 v 5:13 Simon Lees napsal(a):
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 pull in packages that wouldn't work on there system.
That's the purpose I emphatically do not want to support. Devel projects are devel projects because they are for development of packages for Factory. That's it.
erm, no, not in such general way.
We used to have them always as devel area for factory, but got also testing from the users of stable distributions.
IIRC only the python folks decided to split factory and leap builds into two seperate projects, dunno why.
Something along the lines of users kept adding d:l:p to there Leap setups which would then cause unintended consequences as extra packages would be swapped and many things would break. d:l:p then disabled publishing for Leap to prevent this but some people inside SUSE needed this and some people in the community weren't that happy, so backports was created to 1. as Matej said meet the need of the people inside SUSE and 2. to make it less likely that users who installed this repo would completely break there systems. -- 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
Dne 10. 01. 22 v 8:37 Simon Lees napsal(a):
Something along the lines of users kept adding d:l:p to there Leap setups which would then cause unintended consequences as extra packages would be swapped and many things would break. d:l:p then disabled publishing for Leap to prevent this but some people inside SUSE needed this and some people in the community weren't that happy, so backports was created to 1. as Matej said meet the need of the people inside SUSE and 2. to make it less likely that users who installed this repo would completely break there systems.
Let me suggest this two-fold solution: 1. We will stop publishing packages from Leap/SLE repositories of d:l:p. If you want to pull from d:l:p:* you have d:l:p:backports for it. 2. If there is any consensus, what should be added to project configuration of d:l:p:backports, I will gladly add it, just with the caveats mentioned before (absolutely not maintenance aside from running backports_repo.py from time to time, so that the packages there are just a mirror of packages in Factory). Any thoughts? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 It took me fifteen years to discover I had no talent for writing, but I couldn’t give it up, because by that time I was too famous. -- Robert Benchley
On 1/10/22 19:19, Matěj Cepl wrote:
Dne 10. 01. 22 v 8:37 Simon Lees napsal(a):
Something along the lines of users kept adding d:l:p to there Leap setups which would then cause unintended consequences as extra packages would be swapped and many things would break. d:l:p then disabled publishing for Leap to prevent this but some people inside SUSE needed this and some people in the community weren't that happy, so backports was created to 1. as Matej said meet the need of the people inside SUSE and 2. to make it less likely that users who installed this repo would completely break there systems.
Let me suggest this two-fold solution:
1. We will stop publishing packages from Leap/SLE repositories of d:l:p. If you want to pull from d:l:p:* you have d:l:p:backports for it.
2. If there is any consensus, what should be added to project configuration of d:l:p:backports, I will gladly add it, just with the caveats mentioned before (absolutely not maintenance aside from running backports_repo.py from time to time, so that the packages there are just a mirror of packages in Factory).
Any thoughts?
Sounds reasonable to me, from memory this resembles the setup we had when backports was first 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
On 1/10/22 08:39, Matěj Cepl wrote:
Dne 09. 01. 22 v 5:13 Simon Lees napsal(a):
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 pull in packages that wouldn't work on there system.
That's the purpose I emphatically do not want to support. Devel projects are devel projects because they are for development of packages for Factory. That's it.
I'm certainly not suggesting that we as a project should support people using it but it was certainly designed so that it would break less then when people used d:l:p which we knew would almost certainly break stuff if you didn't know exactly what you were doing. -- 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 Sonntag, 9. Januar 2022, 23:09:29 CET schrieb Matěj Cepl:
Dne 09. 01. 22 v 5:13 Simon Lees napsal(a):
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 pull in packages that wouldn't work on there system.
That's the purpose I emphatically do not want to support. Devel projects are devel projects because they are for development of packages for Factory. That's it.
I feel this as well. I try the following approach: include <path project="openSUSE:Leap:15.3:Update" repository="standard"/> as build target for 15.3, branch packages as required and potentially keep them in an older state (supporting Py 3.6). Disable build for these packages and other repos, namely TW. This is not ideal, but at least allows to keep a working set of packages... Cheers Axe
participants (5)
-
Adrian Schröter -
Axel Braun -
Ben Greiner -
Matěj Cepl -
Simon Lees