[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-packaging
Subject:    Re: Different source package versions building library with identical soname
From:       Richard Biener <rguenther () suse ! de>
Date:       2022-03-28 6:51:49
Message-ID: o3129n6p-419-6r31-7nqr-r3op55571n4o () fhfr ! qr
[Download RAW message or body]

On Sun, 27 Mar 2022, Aaron Puchert wrote:

> Hi,
> 
> I want to submit a package into Factory that provides a library with an soname
> identical to that provided by another package, but this seems to conflict with
> the convention to name such packages lib%{name}%{sonum}, since obviously the
> packages can't share the same name. [1]
> 
> The background: Clang has both a stable API (the "C API" in libclang.so) and
> an instable API (the "C++ API" in libclang-cpp.so). Now upstream noticed that
> this should perhaps be reflected by not increasing the so number of
> libclang.so [2], so that with LLVM 14 we now have
> 
> libclang-cpp.so -> libclang-cpp.so.14
> libclang-cpp.so.14
> libclang.so -> libclang.so.13
> libclang.so.13 -> libclang.so.14.0.0
> libclang.so.14.0.0
> 
> Of course libclang-cpp.so.* libraries need to be able to coexist, whereas
> libclang.so cannot coexist with the previous version that provides
> 
> libclang.so.13 -> libclang.so.13.0.1
> 
> So I have to split up the libraries. But then both package versions provide
> 
> libclang.so.13()(64bit)
> libclang.so.13(LLVM_13)(64bit)
> 
> Indeed only the newer version should ever be needed, so should I stop building
> the older version or, more realistically, don't package it? (There are
> binaries in clang13 that use it, so I can't stop building or shipping it that
> easily. These binaries should of course also work with libclang.so.13 provided
> by LLVM 14.) Easier would be to keep shipping the old package, but have the
> new version obsolete it. Is that enough?
> 
> Additionally, how should I name that package? Of course I can't also call it
> libclang13 unless I modify the LLVM 13 packaging to remove the library there,
> so should it be libclang14 or libclang13-14? The former would be the easiest,
> but rpmlint doesn't like it:
> 
> libclang14.x86_64: E: shlib-policy-name-error SONAME: libclang.so.13, expected
> package suffix: 13

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.

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).  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)

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


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}}


(it was some trial-and-error to find a way that works across SLE10 to
Factory).

So my advice would be to go a similar way for the stable ABI libraries.

Our rpmlintrc has

# We have names lib libgcc_s1-gcc7 for non-default GCCs
addFilter ("shlib-policy-name-error")

and the -gccN suffixed packages never end up on any product media in SLE.

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)


[prev in list] [next in list] [prev in thread] [next in thread]