
On Tue, 5 Apr 2022, Jan Engelhardt wrote:
On Monday 2022-04-04 23:44, Aaron Puchert wrote:
# 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?
The Wiki doesn't leave this loophole, in fact there is no exception at all for our case. [1] [1] <https://en.opensuse.org/openSUSE:Shared_library_packaging_policy>
The Rationale section is non-normative, but still informative (guidance-giving)::
"[...] make it possible to use multiple shared libraries that share the same name stem but having different SO version".
A package set like {libgcc_s1-gcc7, libgcc_s1-gcc8, etc.} all have the *same* SO version. One could argue the policy is not applicable.
Note that the fact that we use suffixes at all instead of just building libgcc_s1 from more than one source rpm is due to (old?) restrictions of tooling which had no way to distinguish the different versions and ended up picking a random one to put on the media or to use for building packages with useforbuild. I believe that to some extent those limitations still exist even if the behavior is now maybe less random, but eventually still not as desired (like if it would always pick the last built one). Michael can probably confirm for sure if there's still tools limitations.
Do we want to define a naming scheme for libraries where the same SONAME is generated by multiple source packages? The library packages can't have the same name then.
It is a bit difficult to detect name (mis-)compliance: Mesa-libGL1.rpm is normally flagged as "there is no Mesa-libGL.so.1 in this package" and libgcc_s1-gcc8 as "there is no libgcc_s1-gcc.so.8 in this package". Existing practice is few and far between (off the top of my head, just gccX/gccY, Mesa/nvidia and now llvmX/llvmY). I'd say let's just treat it as exceptional.
Agreed. Note that since we know at build time whether the package is suffixed (aka irrelevant) if there was a way to signal the rpmbuild result consumer it would be possible to simply throw those packages away (IIRC for old products we indeed rm'ed the rpms from the built packages directory at some carefully chosen %<step> time which did this trick). Like maybe %package -n libgcc_s1-gcc7 #!BuildThrowaway ... or so. That would work to throw away older versions of the same shared library package but of course would not work to introduce a newer (but not yet supposed to be default) version - that would still need to have an alternate name, also to avoid exposing an update path. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)