https://bugzilla.suse.com/show_bug.cgi?id=1183960 https://bugzilla.suse.com/show_bug.cgi?id=1183960#c3 --- Comment #3 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1183960) was mentioned in https://build.opensuse.org/request/show/881821 Factory / ncurses -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1183960 https://bugzilla.suse.com/show_bug.cgi?id=1183960#c6 Michael Matz <matz@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matz@suse.com --- Comment #6 from Michael Matz <matz@suse.com> --- An even more aggressive solution would be to stop having the pcre2-posix library at all. Sources that consciously want the pcre2 variant of the POSIX regex facility can include pcre2posix.h without other changes in their sources and link against libpcre2 (without -posix). And sources who do not consciously want pcre2 under the POSIX names wouldn't link against libpcre2-posix anyway. So providing libpcre2-posix at all seems to be a mere rope waiting to be hanged by. But if the above is deemed too aggressive, then yeah, at least moving it to a separate package, not pulled in by mere chance, and making sure that no libraries we provide link against it, would be a solution as well. So, thanks for doing that :-) (I came from the gdb side via ncurses to look at this, and my initial reaction was: ncurses linking against pcre2-posix? ugh, disaster in waiting :) ) -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1183960 https://bugzilla.suse.com/show_bug.cgi?id=1183960#c8 --- Comment #8 from Cristian Rodr�guez <crrodriguez@opensuse.org> --- (In reply to Michael Matz from comment #6)

An even more aggressive solution would be to stop having the pcre2-posix library at all. Sources that consciously want the pcre2 variant of the POSIX regex facility can include pcre2posix.h without other changes in their sources and link against libpcre2 (without -posix). And sources who do not consciously want pcre2 under the POSIX names wouldn't link against libpcre2-posix anyway. So providing libpcre2-posix at all seems to be a mere rope waiting to be hanged by.

But if the above is deemed too aggressive, then yeah, at least moving it to a separate package, not pulled in by mere chance, and making sure that no libraries we provide link against it, would be a solution as well. So, thanks for doing that :-) (I came from the gdb side via ncurses to look at this, and my initial reaction was: ncurses linking against pcre2-posix? ugh, disaster in waiting :) )

I also played now with the possibility of also making the confliciting symbol names compat symbols for old binaries only,.. found no way of doing this without breaking the ABI anyway if the current library which is installed on user's systems already lacks of existing versioning. 1 . Adding versioning == ABI break 2. plainly removing old symbols == ABI break 3. making pcre-posix old regcomp and friends symbols compat symbols goto 1. 4. using linker --default-symver uglier and goto 1 5. changing the library soname and fixing it correctly defeats all the point of this excercise which is that I only care of old binaries linked rightly or not to this library, the newely built ones do not really matter. Do you know any other option ? afaik and extensive googling was unsucessful. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1183960 https://bugzilla.suse.com/show_bug.cgi?id=1183960#c10 --- Comment #10 from Cristian Rodr�guez <crrodriguez@opensuse.org> --- (In reply to Michael Matz from comment #9)

(In reply to Cristian Rodr�guez from comment #8)

...

Do you know any other option ? afaik and extensive googling was unsucessful.

Merely providing a symbol version when there was none before shouldn't break existing uses (the referenced unversioned symbols will be satisfied by the lowest versioned one). But you can't remove the symbols in that way, that will always entail a soname bump.

But we can ask ourself if we ever want to be able to produce _new_ libs/binaries that link against libpcre2-posix (and use the POSIX symbol names). A way to do that would be to move the prefixed functions from that lib into libpcre2 itself: pcre2_regcomp, pcre2_regerror, pcre2_regfree, pcre2_regexec. Then provide a mostly empty libpcre2-posix.so.2 (for old libs/binaries, i.e. containing the POSIX names), but _not_ provide the libpcre2-posix.so symlink. In that way nothing within openSUSE could link edit new libs/binaries anymore that would run into this problem. Over time the existing binaries and libs at users system that still make use of libpcre2-posix will be gone, at which point we then also can remove the libpcre2-posix2 package.

(The reason for moving the functions is so that sources that make validly use of <pcre2posix.h> and hence reference pcre2_regcomp for instance can continue to be built, but they would need linking against libpcre2 proper, instead of against libpcre2-posix, which in that model isn't possible anymore).

Of course, moving the functions from one to the other lib should not be done without buy-in from upstream.

This sounds straightforward but .. all of this for.. I checked the debian archive.. there is ONE package using this library and it is probably by mistake. TW otoh currently has few dozen only because they were infected indirectly, once ncurses hits factory the list will shrink to a few or none. -- You are receiving this mail because: You are on the CC list for the bug.