Hi Richard, Thanks for the detailed answer, which I'm still processing. Am 28.03.22 um 08:51 schrieb Richard Biener:
Yes, OBS plays not nice with this situation. But what should direct you to the solution is rpm/zypp which do not handle auto-updating of packages with different names. For example if you had libclang13-llvm13 and libclang13-llvm14 which should be possible with an entry into the exception table then you need Provide/Obsoletes entries for those libraries that will be an ever growing list. Indeed a versioned Provides/Obsoletes on something like libclang13 doesn't cause zypper to update from one to the other, but it seems to have removed a previous libclang13. So Obsoletes works properly only for actual package names, not for anything they provide? (In this way it would be different than Conflicts?) For GCC we shift the pain to the OBS side by packaging
%package -n libgcc_s%{libgcc_s}%{libgcc_s_suffix}
where %{libgcc_s_suffix} is either empty (GCC version selected by the OBS projconf) or of the form '-gcc<version>' where the suffixed package versions will be never auto-installed/updated (but a user can choose to manually install newer versions).
Let's say I have libgcc_s1-gcc12 installed, which is not the default yet. Would this migrate me to libgcc_s1 when you update the default GCC, and have you any special mechanism for that? Might not be an issue for me since we usually switch the default LLVM right away, but would be good to know.
OBS in the project config then adds magic to select the gcc version plus has
Prefer: libgcc_s1
(because otherwise it wouldn't know whether to install libgcc_s1 or libgcc_s1-gcc10 for example) Seems I'll need that as well, otherwise OBS doesn't know what to choose for resolving e.g. 'libclang.so.13()(64bit)'. Since in GCC we have multiple stable ABI libraries but some do change SONAMEs at some point and thus which GCC version provides exactly which stable ABI library depends on the library (not sure if you are there yet) the project config has entries like
# The following shlibs have the latest version built from GCC 10 sources %product_libs_gcc_ver_libgphobos1 10 %product_libs_gcc_ver_libgdruntime1 10 %product_libs_gcc_ver_libgo16 10
in addition to
# define which gcc package builds the system libraries %product_libs_gcc_ver 11
So "%product_libs_gcc_ver 11" selects gcc11 for producing the newest SONAME of all libraries, while the other variables only select which gcc version produces an older SONAME, right? Since for now I'll only touch llvm13 and llvm14, I wouldn't need this and could go with a single %product_libs_llvm_ver 14 but of course we might need a %product_libs_llvm_ver_libclang13 XXX should we get a libclang14 some day.
To use those we have (just quoting the simple case of libgcc_s1):
%define libgcc_s_suffix %{plv libgcc_s %{libgcc_s}}
with
%define itsme11 1 %define plv_ %{!?product_libs_gcc_ver:11}%{?product_libs_gcc_ver} %define plv() %{expand:%%{!?itsme%{expand:%%{!?product_libs_gcc_ver_%{1}%{2}:%%{plv_}}%%{?product_libs_gcc_ver_%{1}%{2}}}:-gcc11}} Got it, that decides whether we need a suffix or not, or rather what the suffix is going to be. Our rpmlintrc has
# We have names lib libgcc_s1-gcc7 for non-default GCCs addFilter ("shlib-policy-name-error") It seems that going with a prefix instead of a suffix makes that check happy. Currently I have llvm14-libclang13. Maybe this is a bad idea though?
Aaron