Global fix for "have choice for pkgconfig(icu-uc) needed by harfbuzz-devel: icu.691-devel libicu-devel"
Hi, currently, many packages in repositories based on openSUSE:Leap:15.{4,5} fail with the above error message. See e.g. [1] for quite some occurences. Another affected base repository is openSUSE:Backports:SLE-15-SP5. Repositories based on openSUSE:Leap:15.{4,5}:Update are fine. Some projects have worked around this by adding "Prefer: icu-devel" to their project config, while SUSE:SLE-15-SP4:Update [2] has: --- #request by dcermak 2023-01-25 #modified request by fvogdt 2023-01-27 #modified request by dmueller 2023-09-15 Prefer: -libicu60_2 -libicu69 -libicu-suse65_1 --- The current state is IMHO quite messy, and leaving this up to the individual projects is wrong. The packages inherited from openSUSE:Leap:15.5 should be in a consistent state, without need for any local fixups. So, can someone please add the actually correct lines to the relevant base projects? Kind regards, Stefan [1] https://www.google.com/search?q=opensuse+have+choice+harfbuzz+icu.691-devel [2] https://build.opensuse.org/projects/SUSE:SLE-15-SP4:Update/prjconf -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
Hi, On Fri, Dec 08, 2023 at 12:42:06AM +0100, Stefan Brüns wrote:
Hi,
currently, many packages in repositories based on openSUSE:Leap:15.{4,5} fail with the above error message. See e.g. [1] for quite some occurences. Another affected base repository is openSUSE:Backports:SLE-15-SP5.
Repositories based on openSUSE:Leap:15.{4,5}:Update are fine.
Some projects have worked around this by adding "Prefer: icu-devel" to their project config, while SUSE:SLE-15-SP4:Update [2] has:
--- #request by dcermak 2023-01-25 #modified request by fvogdt 2023-01-27 #modified request by dmueller 2023-09-15 Prefer: -libicu60_2 -libicu69 -libicu-suse65_1 ---
The current state is IMHO quite messy, and leaving this up to the individual projects is wrong. The packages inherited from openSUSE:Leap:15.5 should be in a consistent state, without need for any local fixups.
So, can someone please add the actually correct lines to the relevant base projects?
Does this also happen if you use openSUSE:Backports:SLE-15-SP5:Update? We set this in SUSE:SLE-15:Update: # darix added 20230911 requested by meissner Prefer: libicu73_2-devel And this config should inherit through all of the project chain if you use :Update Ciao, Marcus
On Friday 2023-12-08 09:01, Marcus Meissner wrote:
On Fri, Dec 08, 2023 at 12:42:06AM +0100, Stefan Brüns wrote:
We set this in SUSE:SLE-15:Update:
# darix added 20230911 requested by meissner Prefer: libicu73_2-devel
And this config should inherit through all of the project chain if you use :Update
But it's pointless(?), because icu.691 adds icu-69 (to the preexisting icu-65), not 73.
On Fri, Dec 08, 2023 at 09:03:50AM +0100, Jan Engelhardt wrote:
On Friday 2023-12-08 09:01, Marcus Meissner wrote:
On Fri, Dec 08, 2023 at 12:42:06AM +0100, Stefan Brüns wrote:
We set this in SUSE:SLE-15:Update:
# darix added 20230911 requested by meissner Prefer: libicu73_2-devel
And this config should inherit through all of the project chain if you use :Update
But it's pointless(?), because icu.691 adds icu-69 (to the preexisting icu-65), not 73.
I dug deeper and the problem is: - We released harbuzz-devel switching its Requires: libicu-devel to Requires: pkgconfig(icu-uc) As we released icu.691 in SP3:Update that introduces this choice, I asked our buildteam to add Prefer: -libicu-devel in SP3:Update projectconfig, so either icu.691 or icu73_2 gets picked up for build (GA / Update) in the SP4 / 15.4 / SP5 / 15.5 GA projects. Ciao, Marcus
On Friday 2023-12-08 09:16, Marcus Meissner wrote:
As we released icu.691 in SP3:Update that introduces this choice, I asked our buildteam to add
Prefer: -libicu-devel
in SP3:Update projectconfig, so either icu.691 or icu73_2 gets picked up for build (GA / Update) in the SP4 / 15.4 / SP5 / 15.5 GA projects.
But then you get have choice for pkgconfig(icu-uc): icu.691-devel icu73_2-devel don't you? (Because SP5 inherits everything released previously)
On Fri, Dec 08, 2023 at 10:24:23AM +0100, Jan Engelhardt wrote:
On Friday 2023-12-08 09:16, Marcus Meissner wrote:
As we released icu.691 in SP3:Update that introduces this choice, I asked our buildteam to add
Prefer: -libicu-devel
in SP3:Update projectconfig, so either icu.691 or icu73_2 gets picked up for build (GA / Update) in the SP4 / 15.4 / SP5 / 15.5 GA projects.
But then you get
have choice for pkgconfig(icu-uc): icu.691-devel icu73_2-devel
don't you? (Because SP5 inherits everything released previously)
This is solved by the Prefer: libicu73_2-devel in SUSE:SLE-15:Update Ciao, Marcus
On Fri, Dec 08, 2023 at 10:24:23AM +0100, Jan Engelhardt wrote:
On Friday 2023-12-08 09:16, Marcus Meissner wrote:
As we released icu.691 in SP3:Update that introduces this choice, I asked our buildteam to add
Prefer: -libicu-devel
in SP3:Update projectconfig, so either icu.691 or icu73_2 gets picked up for build (GA / Update) in the SP4 / 15.4 / SP5 / 15.5 GA projects.
But then you get
have choice for pkgconfig(icu-uc): icu.691-devel icu73_2-devel
don't you? (Because SP5 inherits everything released previously)
The choice between icu.691 and icu should now be fixed hopefully in all places. (And Stefan in case you still see it, your email is full ;) Ciao, Marcus
On Freitag, 8. Dezember 2023 09:01:14 CET Marcus Meissner wrote:
Hi,
On Fri, Dec 08, 2023 at 12:42:06AM +0100, Stefan Brüns wrote:
Hi,
currently, many packages in repositories based on openSUSE:Leap:15.{4,5} fail with the above error message. See e.g. [1] for quite some occurences. Another affected base repository is openSUSE:Backports:SLE-15-SP5.
Repositories based on openSUSE:Leap:15.{4,5}:Update are fine.
Some projects have worked around this by adding "Prefer: icu-devel" to their project config, while SUSE:SLE-15-SP4:Update [2] has:
--- #request by dcermak 2023-01-25 #modified request by fvogdt 2023-01-27 #modified request by dmueller 2023-09-15 Prefer: -libicu60_2 -libicu69 -libicu-suse65_1 ---
The current state is IMHO quite messy, and leaving this up to the individual projects is wrong. The packages inherited from openSUSE:Leap:15.5 should be in a consistent state, without need for any local fixups.
So, can someone please add the actually correct lines to the relevant base projects?
Does this also happen if you use openSUSE:Backports:SLE-15-SP5:Update?
We set this in SUSE:SLE-15:Update:
# darix added 20230911 requested by meissner Prefer: libicu73_2-devel
And this config should inherit through all of the project chain if you use :Update
Someone apparently has changed some project configuration, as I can't see the resolution ambiguities any longer. A heads up to the list would have been very welcome. But nevertheless, I think there are still several problems here: 1. When adding a repository via the OBS UI ("Add from a distribution"), you end up with a non-:Update repository, no matter if you select "openSUSE Backports for SLE 15 SP5" or "openSUSE Leap 15.5". So the default choice would be broken. And you have to edit the XML files to fix it. 2. As far as I can see, 15.5 does not have libicu73*, so the Prefer: is a no- op. But is does have icu65.1 (from SLE15) and icu69.1 (from SLE15SP4). 3. Mixing multiple versions of the same shared library is in general a very bad thing. I can see the build host installs both libicu 65.1 and 69.1, so binaries may end up with linking to both versions (directly and indirectly). For libicu, this is probably mostly fine, as almost[1] all symbols are namespace-prefixed (e.g. icu_65::) for suffixed (e.g. _65), but for other libraries this may be actual problem. (For large parts, I consider the SLPP as actually harmful, as there is *no* safeguard for this to happen, and applications can break in various hard to diagnose ways.) Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On Freitag, 8. Dezember 2023 18:54:50 CET Stefan Brüns wrote:
2. As far as I can see, 15.5 does not have libicu73*, so the Prefer: is a no- op. But is does have icu65.1 (from SLE15) and icu69.1 (from SLE15SP4).
Regarding the build pulling in both versions, this seems to be caused by webkit2gtk3 [1]. It has BuildRequires for "pkgconfig(harfbuzz)" and "icu- devel", and while the harfbuzz library is linked to one specific (but unknown) ICU version, icu-devel pulls in libicu65.1, which probably is a different one. (Half-OT-Rant: Why are build logs for Leap and SLE totally inaccessible, and also all dependency information? Everything is "excluded", and built artifacts are apparently non-existent, all relevant information is hidden in a black box.) Regards, Stefan [1] https://build.opensuse.org/package/show/SUSE:SLE-15-SP4:Update/webkit2gtk3 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On 08.12.2023 21:20, Stefan Brüns wrote:
On Freitag, 8. Dezember 2023 18:54:50 CET Stefan Brüns wrote:
(Half-OT-Rant: Why are build logs for Leap and SLE totally inaccessible, and also all dependency information? Everything is "excluded", and built artifacts are apparently non-existent, all relevant information is hidden in a black box.)
Because build happens on black box and only resulting binaries are imported. I totally agree with you and it is super annoying and does not help anyone attempting to contribute.
On Fri, Dec 08, 2023 at 06:54:50PM +0100, Stefan Brüns wrote:
On Freitag, 8. Dezember 2023 09:01:14 CET Marcus Meissner wrote:
Hi,
On Fri, Dec 08, 2023 at 12:42:06AM +0100, Stefan Brüns wrote:
Hi,
currently, many packages in repositories based on openSUSE:Leap:15.{4,5} fail with the above error message. See e.g. [1] for quite some occurences. Another affected base repository is openSUSE:Backports:SLE-15-SP5.
Repositories based on openSUSE:Leap:15.{4,5}:Update are fine.
Some projects have worked around this by adding "Prefer: icu-devel" to their project config, while SUSE:SLE-15-SP4:Update [2] has:
--- #request by dcermak 2023-01-25 #modified request by fvogdt 2023-01-27 #modified request by dmueller 2023-09-15 Prefer: -libicu60_2 -libicu69 -libicu-suse65_1 ---
The current state is IMHO quite messy, and leaving this up to the individual projects is wrong. The packages inherited from openSUSE:Leap:15.5 should be in a consistent state, without need for any local fixups.
So, can someone please add the actually correct lines to the relevant base projects?
Does this also happen if you use openSUSE:Backports:SLE-15-SP5:Update?
We set this in SUSE:SLE-15:Update:
# darix added 20230911 requested by meissner Prefer: libicu73_2-devel
And this config should inherit through all of the project chain if you use :Update
Someone apparently has changed some project configuration, as I can't see the resolution ambiguities any longer. A heads up to the list would have been very welcome.
I did update the list, but you did not get them, your mailbox was full. ;)
But nevertheless, I think there are still several problems here:
1. When adding a repository via the OBS UI ("Add from a distribution"), you end up with a non-:Update repository, no matter if you select "openSUSE Backports for SLE 15 SP5" or "openSUSE Leap 15.5". So the default choice would be broken. And you have to edit the XML files to fix it.
This is now resolved, and yes it should not happen.
2. As far as I can see, 15.5 does not have libicu73*, so the Prefer: is a no- op. But is does have icu65.1 (from SLE15) and icu69.1 (from SLE15SP4).
Yes, icu73_2 was not involved. In SUSE:SLE-15-SP3:Update I added a deprefer now Prefer: -libicu-devel so it will pick the icu69.1 choice.
3. Mixing multiple versions of the same shared library is in general a very bad thing. I can see the build host installs both libicu 65.1 and 69.1, so binaries may end up with linking to both versions (directly and indirectly). For libicu, this is probably mostly fine, as almost[1] all symbols are namespace-prefixed (e.g. icu_65::) for suffixed (e.g. _65), but for other libraries this may be actual problem.
Yes, fully aware of that.
(For large parts, I consider the SLPP as actually harmful, as there is *no* safeguard for this to happen, and applications can break in various hard to diagnose ways.)
Yes. Ciao, Marcus
On Friday 2023-12-08 18:54, Stefan Brüns wrote:
3. Mixing multiple versions of the same shared library is in general a very bad thing. I can see the build host installs both libicu 65.1 and 69.1, so binaries may end up with linking to both versions (directly and indirectly). For libicu, this is probably mostly fine, as almost[1] all symbols are namespace-prefixed (e.g. icu_65::) for suffixed (e.g. _65), but for other libraries this may be actual problem.
Symbol versioning (even a very trivial one) also acts as namespacing and does not need source modification (like the ICU namespace thing). This is how libssl.so.1/libssl.so.3 can reasonably coexist within the same process. It's not rocket science and takes just two lines in a Makefile. Any developer not doing symvers should feel guilty already.
participants (4)
-
Andrei Borzenkov
-
Jan Engelhardt
-
Marcus Meissner
-
Stefan Brüns