Drop openSUSE_Leap_* repos from OBS multimedia and M17N projects
Hi, in a few OBS projects I'm maintaining contain both openSUSE_Leap_15.* and 15.* repositories, both of which point basically to the very same targets. It means that we build unnecessarily twice for all packages. Now as the 15.* (15.3 and 15.4) repos are officially recommended ones, for reducing the waste of resources, I'm going to drop the openSUSE_Leap_15.3 and openSUSE_Leap_15.4 repos from the following OBS projects: - multimedia:libs - multimedia:apps - M17N - M17N:fonts It means: if anyone is using those projects with the openSUSE_Leap_15.3 or openSUSE_Leap_15.4 repo, please switch to 15.3 or 15.4 repo, respectively. The drop of openSUSE_Leap_* repos is planned to be done after a couple of weeks, probably in the week 36. If you have concerns or requirements that those repos must retain, please let me know. thanks, Takashi
Hi Takashi, On Fri, 19 Aug 2022, 09:29:24 +0200, Takashi Iwai wrote:
Hi,
in a few OBS projects I'm maintaining contain both openSUSE_Leap_15.* and 15.* repositories, both of which point basically to the very same targets. It means that we build unnecessarily twice for all packages.
Now as the 15.* (15.3 and 15.4) repos are officially recommended ones, for reducing the waste of resources, I'm going to drop the openSUSE_Leap_15.3 and openSUSE_Leap_15.4 repos from the following OBS projects:
- multimedia:libs - multimedia:apps - M17N - M17N:fonts
It means: if anyone is using those projects with the openSUSE_Leap_15.3 or openSUSE_Leap_15.4 repo, please switch to 15.3 or 15.4 repo, respectively.
The drop of openSUSE_Leap_* repos is planned to be done after a couple of weeks, probably in the week 36.
If you have concerns or requirements that those repos must retain, please let me know.
the only concern I have is that Leap users don't necessarily read the factory list. I'd suggest you post this to a more general list, too.
thanks,
Takashi
Cheers. l8er manfred
Sorry Takashi, I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it. Greetings Eric Am 19. August 2022 09:29:24 MESZ schrieb Takashi Iwai <tiwai@suse.de>:
Hi,
in a few OBS projects I'm maintaining contain both openSUSE_Leap_15.* and 15.* repositories, both of which point basically to the very same targets. It means that we build unnecessarily twice for all packages.
Now as the 15.* (15.3 and 15.4) repos are officially recommended ones, for reducing the waste of resources, I'm going to drop the openSUSE_Leap_15.3 and openSUSE_Leap_15.4 repos from the following OBS projects:
- multimedia:libs - multimedia:apps - M17N - M17N:fonts
It means: if anyone is using those projects with the openSUSE_Leap_15.3 or openSUSE_Leap_15.4 repo, please switch to 15.3 or 15.4 repo, respectively.
The drop of openSUSE_Leap_* repos is planned to be done after a couple of weeks, probably in the week 36.
If you have concerns or requirements that those repos must retain, please let me know.
thanks,
Takashi
On Sun, 21 Aug 2022 15:39:21 +0200, Eric Schirra wrote:
Sorry Takashi,
I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it.
I myself don't mind either way, honestly speaking. If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage. Takashi
Greetings Eric
Am 19. August 2022 09:29:24 MESZ schrieb Takashi Iwai <tiwai@suse.de>:
Hi,
in a few OBS projects I'm maintaining contain both openSUSE_Leap_15.* and 15.* repositories, both of which point basically to the very same targets. It means that we build unnecessarily twice for all packages.
Now as the 15.* (15.3 and 15.4) repos are officially recommended ones, for reducing the waste of resources, I'm going to drop the openSUSE_Leap_15.3 and openSUSE_Leap_15.4 repos from the following OBS projects:
- multimedia:libs - multimedia:apps - M17N - M17N:fonts
It means: if anyone is using those projects with the openSUSE_Leap_15.3 or openSUSE_Leap_15.4 repo, please switch to 15.3 or 15.4 repo, respectively.
The drop of openSUSE_Leap_* repos is planned to be done after a couple of weeks, probably in the week 36.
If you have concerns or requirements that those repos must retain, please let me know.
thanks,
Takashi
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
I assumed that the name change was because the repos will contain RPMs for SUSE and openSUSE. -- Roger Oberholtzer
Am 22. August 2022 08:48:36 MESZ schrieb Roger Oberholtzer <roger.oberholtzer@gmail.com>:
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
I assumed that the name change was because the repos will contain RPMs for SUSE and openSUSE.
No, there must have been a vote once. But, if I understood correctly, there was only this poll for 15.4. But 15.3 was already openSUSE_Leap_15.3 before that. But I personally don't care in the meantime. But I think it's very confusing for many others, because you have to be careful in the repos definitions. Regards Eric
On Mon, 22 Aug 2022 08:48:36 +0200, Roger Oberholtzer wrote:
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
I assumed that the name change was because the repos will contain RPMs for SUSE and openSUSE.
... and this brought confusion very much in the end, unfortunately. Practically seen, 15.3 / 15.4 repo setup is primarily targeted only for Leap. If you build a package there, it's not guaranteed to work on SLE, because it's built on the project with a mixture of both SLE and Leap packages. For SLE packages, the repo has to be set up only with the SUSE:SLE-* instead. Takashi
On 8/22/22 09:32, Takashi Iwai wrote:
Practically seen, 15.3 / 15.4 repo setup is primarily targeted only for Leap. If you build a package there, it's not guaranteed to work on SLE, because it's built on the project with a mixture of both SLE and Leap packages. For SLE packages, the repo has to be set up only with the SUSE:SLE-* instead.
The point of this binary "sharing" between SLE and Leap was to allow someone to move from Leap to SLE without re-install. This also means that packages that build require only SLE packages, they really should behave and work like if they are build for SLE. So the repo doesn't need special setup anymore. For example, the Leap 15.4 Update project has this configuration, <path project="openSUSE:Leap:15.4" repository="standard"/> <path project="openSUSE:Backports:SLE-15-SP4:Checks" repository="standard"/> <path project="openSUSE:Backports:SLE-15-SP4:Update" repository="standard"/> <path project="openSUSE:Backports:SLE-15-SP4" repository="standard"/> <path project="SUSE:SLE-15-SP4:Update" repository="pool"/> <path project="SUSE:SLE-15-SP4:GA" repository="pool"/> <path project="SUSE:SLE-15-SP3:Update" repository="pool"/> <path project="SUSE:SLE-15-SP3:GA" repository="pool"/> <path project="SUSE:SLE-15-SP2:Update" repository="pool"/> <path project="SUSE:SLE-15-SP2:GA" repository="pool"/> <path project="SUSE:SLE-15-SP1:Update" repository="pool"/> <path project="SUSE:SLE-15-SP1:GA" repository="pool"/> <path project="SUSE:SLE-15:Update" repository="pool"/> <path project="SUSE:SLE-15:GA" repository="pool"/> So, what you are seeing is Backports + SLE = Leap. The Leap repository doesn't have that many packages in it. I see a few patterns and branding ones. Almost everything lives in Backports or SLE now. (of course, I could be very wrong and I miss some OBS magics) - Adam
On 8/22/22 15:05, Takashi Iwai wrote:
On Sun, 21 Aug 2022 15:39:21 +0200, Eric Schirra wrote:
Sorry Takashi,
I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it.
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
In reality we have a pretty big mix everywhere with 15.3 some repo's changed others didn't this was pretty much at maintainers discretion while as a community we decided on this list that we should use 15.4 rather then openSUSE_ -- 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 22.08.22 um 08:59 schrieb Simon Lees:
On 8/22/22 15:05, Takashi Iwai wrote:
On Sun, 21 Aug 2022 15:39:21 +0200, Eric Schirra wrote:
Sorry Takashi,
I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it.
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
In reality we have a pretty big mix everywhere with 15.3 some repo's changed others didn't this was pretty much at maintainers discretion while as a community we decided on this list that we should use 15.4 rather then openSUSE_
Whoever told him "how they want it" for 'openSUSE_Leap_15.3', was either wrong or speaking for their own special repo. It went the exact other direction in devel:languages:python, where his request to change it back caused everything to break down. https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/thread... I can't find the vote discussion on the mailing list archives anymore but I am pretty sure that it was before the 15.4 times. The change was from openSUSE_Leap_15.3 to 15.3 https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/messag... When you create new repositories through the web-interface (https://build.opensuse.org/projects/<project>/distributions/new), you get '15.3' and '15.4'. And there is a rudimentary explanation behind the "?" for the different variants from which you can choose. So Takashi's initiative is the correct one in unifying stuff. Please don't talk him out of it. - Ben
Am Montag, 22. August 2022, 11:09:51 CEST schrieb Ben Greiner:
In reality we have a pretty big mix everywhere with 15.3 some repo's changed others didn't this was pretty much at maintainers discretion while as a community we decided on this list that we should use 15.4 rather then openSUSE_
Whoever told him "how they want it" for 'openSUSE_Leap_15.3', was either wrong or speaking for their own special repo. It went the exact other direction in devel:languages:python, where his request to change it back caused everything to break down.
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/thread /FEVHW5NBBOZ5ERGIVS3YP6NDD2TTQZR2/
I can't find the vote discussion on the mailing list archives anymore but I am pretty sure that it was before the 15.4 times. The change was from openSUSE_Leap_15.3 to 15.3
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/messag e/CNR7V2SG3UIXLX6NAFHM6N57PFUISZKV/
When you create new repositories through the web-interface (https://build.opensuse.org/projects/<project>/distributions/new), you get '15.3' and '15.4'. And there is a rudimentary explanation behind the "?" for the different variants from which you can choose.
So Takashi's initiative is the correct one in unifying stuff. Please don't talk him out of it.
A few weeks ago I had, just exactly because of double 15.3 in another repo asked how they should be called because I actually do not care. Since I was told openSUSE_Leap_15.3 and 15.4 Agree, write it down and correct times all Repos centrally. Then it has an end with this confusion. Regards Eric
Am 22.08.22 um 11:09 schrieb Ben Greiner:
Am 22.08.22 um 08:59 schrieb Simon Lees:
On 8/22/22 15:05, Takashi Iwai wrote:
On Sun, 21 Aug 2022 15:39:21 +0200, Eric Schirra wrote:
Sorry Takashi,
I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it.
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
In reality we have a pretty big mix everywhere with 15.3 some repo's changed others didn't this was pretty much at maintainers discretion while as a community we decided on this list that we should use 15.4 rather then openSUSE_
Whoever told him "how they want it" for 'openSUSE_Leap_15.3', was either wrong or speaking for their own special repo. It went the exact other direction in devel:languages:python, where his request to change it back caused everything to break down.
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/thread...
I can't find the vote discussion on the mailing list archives anymore but I am pretty sure that it was before the 15.4 times. The change was from openSUSE_Leap_15.3 to 15.3
It was the thread "Survey: code stream name" starting 2021-06-28 And the winner was "15.3".
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/messag...
When you create new repositories through the web-interface (https://build.opensuse.org/projects/<project>/distributions/new), you get '15.3' and '15.4'. And there is a rudimentary explanation behind the "?" for the different variants from which you can choose.
So Takashi's initiative is the correct one in unifying stuff. Please don't talk him out of it.
- Ben
Am 22.08.22 um 12:13 schrieb Manfred Schwarb:
Am 22.08.22 um 11:09 schrieb Ben Greiner:
Am 22.08.22 um 08:59 schrieb Simon Lees:
On 8/22/22 15:05, Takashi Iwai wrote:
On Sun, 21 Aug 2022 15:39:21 +0200, Eric Schirra wrote:
Sorry Takashi,
I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it.
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage. In reality we have a pretty big mix everywhere with 15.3 some repo's changed others didn't this was pretty much at maintainers discretion while as a community we decided on this list that we should use 15.4 rather then openSUSE_
Whoever told him "how they want it" for 'openSUSE_Leap_15.3', was either wrong or speaking for their own special repo. It went the exact other direction in devel:languages:python, where his request to change it back caused everything to break down.
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/thread...
I can't find the vote discussion on the mailing list archives anymore but I am pretty sure that it was before the 15.4 times. The change was from openSUSE_Leap_15.3 to 15.3 It was the thread "Survey: code stream name" starting 2021-06-28
And the winner was "15.3".
Thanks a lot, Manfred! I am not sure why my search on lists.opensuse.org with queries including some of the suggested names never came up with those threads. https://lists.opensuse.org/archives/list/project@lists.opensuse.org/thread/R... https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/3... There was also the announcement in the News section on build.opensuse.org, but I can't find any history there. There really should be a proper documentation about it. It obviously still confuses people.
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/messag...
When you create new repositories through the web-interface (https://build.opensuse.org/projects/<project>/distributions/new), you get '15.3' and '15.4'. And there is a rudimentary explanation behind the "?" for the different variants from which you can choose.
So Takashi's initiative is the correct one in unifying stuff. Please don't talk him out of it.
- Ben
On 8/22/22 18:39, Ben Greiner wrote:
Am 22.08.22 um 08:59 schrieb Simon Lees:
On 8/22/22 15:05, Takashi Iwai wrote:
On Sun, 21 Aug 2022 15:39:21 +0200, Eric Schirra wrote:
Sorry Takashi,
I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it.
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
In reality we have a pretty big mix everywhere with 15.3 some repo's changed others didn't this was pretty much at maintainers discretion while as a community we decided on this list that we should use 15.4 rather then openSUSE_
Whoever told him "how they want it" for 'openSUSE_Leap_15.3', was either wrong or speaking for their own special repo. It went the exact other direction in devel:languages:python, where his request to change it back caused everything to break down.
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/thread...
I can't find the vote discussion on the mailing list archives anymore but I am pretty sure that it was before the 15.4 times. The change was from openSUSE_Leap_15.3 to 15.3
The decision was made for 15.4 before it was released (So that 15.4 was consistent when repos were created), some maintainers also chose to retrospectively do the change for 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
On Mon, 22 Aug 2022 12:19:08 +0200, Simon Lees wrote:
On 8/22/22 18:39, Ben Greiner wrote:
Am 22.08.22 um 08:59 schrieb Simon Lees:
On 8/22/22 15:05, Takashi Iwai wrote:
On Sun, 21 Aug 2022 15:39:21 +0200, Eric Schirra wrote:
Sorry Takashi,
I don't think that's right. Because a few weeks ago I asked for exactly the same reason how the repos should be called, because you can't find a description/guideline anywhere. I was told: openSUSE_Leap_15.3 15.4 One long and one short. Well. That's how they want it.
I myself don't mind either way, honestly speaking.
If there is neither proper guide line nor official recommendation, I don't mind even to keep them as is, and proactively ignore any complaints about the resource usage.
In reality we have a pretty big mix everywhere with 15.3 some repo's changed others didn't this was pretty much at maintainers discretion while as a community we decided on this list that we should use 15.4 rather then openSUSE_
Whoever told him "how they want it" for 'openSUSE_Leap_15.3', was either wrong or speaking for their own special repo. It went the exact other direction in devel:languages:python, where his request to change it back caused everything to break down.
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/thread...
I can't find the vote discussion on the mailing list archives anymore but I am pretty sure that it was before the 15.4 times. The change was from openSUSE_Leap_15.3 to 15.3
The decision was made for 15.4 before it was released (So that 15.4 was consistent when repos were created), some maintainers also chose to retrospectively do the change for 15.3
OK, after all, the below sounds like the likely-safe action: - openSUSE_Leap_15.4 is an incorrect repo setup, and should be dropped; either immediately or after some grace period. - openSUSE_Leap_15.3 seems already having some hanging users, and the coexistence with 15.3 seems more or less admitted. We may leave this for now until EOL of Leap 15.3. thanks, Takashi
Am 22.08.22 um 13:11 schrieb Takashi Iwai:
- openSUSE_Leap_15.3 seems already having some hanging users, and the coexistence with 15.3 seems more or less admitted. We may leave this for now until EOL of Leap 15.3.
You could set up the duplicate name as non-building and inheriting from a path to the other one in order to save some computing resource usage. Something like: <project name="multimedia:libs"> ... <build> <disable repository="openSUSE_Leap_15.3"/> </build> <repository name="15.3"> <path project="openSUSE:Leap:15.3:Update" repository="standard"/> <arch>x86_64</arch> <arch>i586</arch> <arch>aarch64</arch> </repository> <repository name="openSUSE_Leap_15.3"> <path project="multimedia:libs" repository="15.3"/> <arch>x86_64</arch> <arch>i586</arch> <arch>aarch64</arch> </repository> </project> This will only produce duplicate builds on newly branched projects, which branch both repositories.
thanks,
Takashi
On Mon, 22 Aug 2022 15:44:34 +0200, Ben Greiner wrote:
Am 22.08.22 um 13:11 schrieb Takashi Iwai:
- openSUSE_Leap_15.3 seems already having some hanging users, and the coexistence with 15.3 seems more or less admitted. We may leave this for now until EOL of Leap 15.3.
You could set up the duplicate name as non-building and inheriting from a path to the other one in order to save some computing resource usage. Something like:
<project name="multimedia:libs"> ... <build> <disable repository="openSUSE_Leap_15.3"/> </build> <repository name="15.3"> <path project="openSUSE:Leap:15.3:Update" repository="standard"/> <arch>x86_64</arch> <arch>i586</arch> <arch>aarch64</arch> </repository> <repository name="openSUSE_Leap_15.3"> <path project="multimedia:libs" repository="15.3"/> <arch>x86_64</arch> <arch>i586</arch> <arch>aarch64</arch> </repository> </project>
This will only produce duplicate builds on newly branched projects, which branch both repositories.
It's an interesting idea. But, with this setup, openSUSE_Leap_15.3 repo will keep only the old built binaries? thanks, Takashi
Am 22.08.22 um 16:16 schrieb Takashi Iwai:
On Mon, 22 Aug 2022 15:44:34 +0200, Ben Greiner wrote:
Am 22.08.22 um 13:11 schrieb Takashi Iwai:
- openSUSE_Leap_15.3 seems already having some hanging users, and the coexistence with 15.3 seems more or less admitted. We may leave this for now until EOL of Leap 15.3. You could set up the duplicate name as non-building and inheriting from a path to the other one in order to save some computing resource usage. Something like:
<project name="multimedia:libs"> ... <build> <disable repository="openSUSE_Leap_15.3"/> </build> <repository name="15.3"> <path project="openSUSE:Leap:15.3:Update" repository="standard"/> <arch>x86_64</arch> <arch>i586</arch> <arch>aarch64</arch> </repository> <repository name="openSUSE_Leap_15.3"> <path project="multimedia:libs" repository="15.3"/> <arch>x86_64</arch> <arch>i586</arch> <arch>aarch64</arch> </repository> </project>
This will only produce duplicate builds on newly branched projects, which branch both repositories. It's an interesting idea. But, with this setup, openSUSE_Leap_15.3 repo will keep only the old built binaries?
Yes, you will have to wipe the old binaries from openSUSE_Leap_15.3. There is a button in the web-interface or do `osc wipebinaries -r openSUSE_Leap_15.3 multimedia:libs`. Then any binary requested from a repository which has '<path project="multimedia:libs" repository="openSUSE_Leap_15.3"/>' will get its packages from whatever it can find up the chain starting at multimedia:libs/15.3 through openSUSE:Leap:15.3:Update/standard and continuing to whatever is defined as link or path there (Leap/Backports/SLE with :Checks/:Update/:GA standard/pool).
thanks,
Takashi
- Ben
On Aug 22 2022, Ben Greiner wrote:
Yes, you will have to wipe the old binaries from openSUSE_Leap_15.3. There is a button in the web-interface or do `osc wipebinaries -r openSUSE_Leap_15.3 multimedia:libs`. Then any binary requested from a repository which has '<path project="multimedia:libs" repository="openSUSE_Leap_15.3"/>' will get its packages from whatever it can find up the chain starting at multimedia:libs/15.3 through
This up-the-chain searching only works when the referring repository has this path element in the last position. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Am 22.08.22 um 16:47 schrieb Andreas Schwab:
On Aug 22 2022, Ben Greiner wrote:
Yes, you will have to wipe the old binaries from openSUSE_Leap_15.3. There is a button in the web-interface or do `osc wipebinaries -r openSUSE_Leap_15.3 multimedia:libs`. Then any binary requested from a repository which has '<path project="multimedia:libs" repository="openSUSE_Leap_15.3"/>' will get its packages from whatever it can find up the chain starting at multimedia:libs/15.3 through This up-the-chain searching only works when the referring repository has this path element in the last position.
Thanks for the input. In this case, please disregard my idea. I realize it won't work either for end-users directly having multimedia:libs in their repository configuration. Like others in this thread I could preface everything with "I don't mind", because I try to not mind about 15.X at all, but on the other hand this duplication of repositories in projects with heavy packages (The reported rebuild type of multimedia:apps for x86_64 alone is 2h [1]), is taking a toll on the server farm, where resources could be spent more meaningfully in other regards. Not to mention the current reduction of available workers, the current electricity crisis in Germany and global warming. So I personally would welcome a global cleanup of duplicate repositories, still building repositories for EOL distributions, and even some heave home projects of users which were not active for several months but had disabled the autocleanup, e.g. [2] - Ben [1] https://build.opensuse.org/projects/multimedia:apps/rebuild_time?arch=x86_64&repository=15.3 [2] https://build.opensuse.org/request/show/998261
On Fri, 19 Aug 2022 09:29:24 +0200 Takashi Iwai wrote:
Hi,
in a few OBS projects I'm maintaining contain both openSUSE_Leap_15.* and 15.* repositories, both of which point basically to the very same targets. It means that we build unnecessarily twice for all packages.
Now as the 15.* (15.3 and 15.4) repos are officially recommended ones, for reducing the waste of resources, I'm going to drop the openSUSE_Leap_15.3 and openSUSE_Leap_15.4 repos from the following OBS projects:
Tangentially related, but consistent naming/versioning of packages built for Leap on OBS would be nice too. Some packages use lp154, some 150400, some $prefix-{lp154|150400}, which makes zypper's version comparing more 'fun' that it needs to be, and leads to unnecessary noise, IMHO. Granted, I know that Leap as we know(and love) it is on the way out, so the effort in addressing this might be considered waste of resources/maintainers time, but still :) Pedja
On 23.08.2022 17:15, Predrag Ivanović wrote:
On Fri, 19 Aug 2022 09:29:24 +0200 Takashi Iwai wrote:
Hi,
in a few OBS projects I'm maintaining contain both openSUSE_Leap_15.* and 15.* repositories, both of which point basically to the very same targets. It means that we build unnecessarily twice for all packages.
Now as the 15.* (15.3 and 15.4) repos are officially recommended ones, for reducing the waste of resources, I'm going to drop the openSUSE_Leap_15.3 and openSUSE_Leap_15.4 repos from the following OBS projects:
Tangentially related, but consistent naming/versioning of packages built for Leap on OBS would be nice too. Some packages use lp154, some 150400,
150400 is not built for Leap, bit for SLE. As long as Leap imports SLE binaries you have to live with it.
some $prefix-{lp154|150400},
I do not understand what you mean.
which makes zypper's version comparing more 'fun' that it needs to be, and leads to unnecessary noise, IMHO.
Granted, I know that Leap as we know(and love) it is on the way out, so the effort in addressing this might be considered waste of resources/maintainers time, but still :)
Pedja
On Tue, 23 Aug 2022 17:41:49 +0300 Andrei Borzenkov wrote:
some $prefix-{lp154|150400},
I do not understand what you mean.
Virtualization repo has virt-manager-4.1.0-Virt.150400.694.2 package for 15.4, for example. Now, if 150400 vs lp154 distinction is there so that it would be easier to see at a glance if the package is from SLE or Leap 'add-on', fair enough, that didn't occur to me, and I apologize for the noise :) Pedja
On Tuesday 2022-08-23 16:15, Predrag Ivanović wrote:
Tangentially related, but consistent naming/versioning of packages built for Leap on OBS would be nice too. Some packages use lp154, some 150400, some $prefix-{lp154|150400},
150400 is for SLE. lp154 is for Leap (which is a superset of SLE).
On Dienstag, 23. August 2022 16:47:26 CEST Jan Engelhardt wrote:
On Tuesday 2022-08-23 16:15, Predrag Ivanović wrote:
Tangentially related, but consistent naming/versioning of packages built for Leap on OBS would be nice too. Some packages use lp154, some 150400, some $prefix-{lp154|150400},
150400 is for SLE. lp154 is for Leap (which is a superset of SLE).
But what do we gain by having different naming schemes? When looking a some relevant RPM macros/variables, both SLE and Leap use % {sle_version} == 150400. We also have "bp154" for the SLE backports repository. Maybe "sle154" would be a better version suffix, distinguishing between different "sources" for packages with different support levels (though this is likely not relevant for Leap users), but keeping the actual version part the same. Kind regards, Stefan
participants (13)
-
Adam Majer
-
Andreas Schwab
-
Andrei Borzenkov
-
Ben Greiner
-
Brüns, Stefan
-
Eric Schirra
-
Jan Engelhardt
-
Manfred Hollstein
-
Manfred Schwarb
-
Predrag Ivanović
-
Roger Oberholtzer
-
Simon Lees
-
Takashi Iwai