On Freitag, 9. Dezember 2022 23:54:31 CET Lee Duncan wrote:
On 12/9/22 14:34, John Paul Adrian Glaubitz wrote:
Hi Lee!
On 12/9/22 23:24, Lee Duncan wrote:
As I said, our open build service handles this fine. But when I submit
this same package to SUSE for SLE, it complains:
[ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 [ 117s] Your package contains a single shared library but is not named after its [ 117s] SONAME.
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink.
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
I don't remember having seen any library package that has a non-single-digit version number in its name.
Adrian
Thank you for your reply! I believe you are likely correct. I did more online OBS packaging guidelines research, and it looks like that is what is done.
https://en.opensuse.org/ openSUSE:Shared_library_packaging_policy#Versioning_schemes
But in my case, this library had an older version:
old: libopeniscsiusr.so.0.1.0 new: libopeniscsiusr.so.0.2.0
No interfaces went away, but new ones were added. FWIW.
So, bottom line, if I change this package name from libopeniscsiusr0_2_0 to libopeniscsiusr0, how will I handle the new version update, i.e. when libopeniscsiusr0_3_0 comes out? (If it ever does)
Dependency tracking for shared libraries is done automatically. Have a look at either the package "Details" on the OBS, or use "rpm -qp --provides <rpm- file>". The *only* correct way to handle ABI updates which are backwards compatible is by using symbol versioning. Such a package provides the library with an ABI version number, and the same with additional tags covering the extended ABI. Any user of the extended ABI will also depend on these additional tags.
Also, if I change the name, won't I need an "obsoletes" clause in the updated SPEC file? And what about "Provides" to cover the library
You need a "Conflicts:" towards the old, incorrectly named file, because both packages contain the same files. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019