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