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. 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) 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 package name I'm "removing" (renaming) e.g.:
%package -n libopeniscsiusr0 Version: 2.1.8 Release: 0 Summary: The iSCSI User-level Library Group: System/Libraries Obsoletes: libopeniscsiusr0_1_0 Obsoletes: libopeniscsiusr0_2_0 # Is this one needed? Provides: libopeniscsiusr0_2_0
-- Lee D