On 12/12/22 03:33, Martin Wilck wrote:
Hi Lee,
On Sat, 2022-12-10 at 11:08 -0800, Lee Duncan wrote:
Hi Everyone:
Thank you for all the replies.
I'm not really an expert at libraries, so I've learned a bunch.
tl;dr -- my problem comes from building with meson and how it sets the SONAME
DETAILS: ======== When this library first appeared from upstream a few yeas ago, I had to package it. I at first named my package "libopeniscsiusr", but the build service complained until I named it "libopeniscsiusr0_1_0". I didn't understand (or care) why, at the time. [It turns out the SONAME was being set to "libopeniscsiusr.so.0.2.0"!]
More recently, when version 0.2.0 of the library came out, I didn't want to change anything in my SPEC file, but OBS made me name the package "libopeniscsiusr0_2_0", again because of the SONAME, though I didn't realize it at the time.
This package used to be build by Make, and the build line *specifically* set the SONAME! Here's basically what it did:
libopeniscsiusr.so.0.2.0: $(CC) $(CFLAGS) -shared -Wl,-soname=$@ -o $@ $(OBJS) $(LDFLAGS) $(LIBADD) ... (create symlinks)
Now I know the SONAME _should_ have been "libopeniscsiusr.so.0".
Recently, I changed this package to build using meson. In meson, I just tell it my library name and version, and it creates the SONAME:
libiscsi_usr = shared_library('openiscsiusr', libiscsi_usr_srcs, include_directories: [libiscsi_usr_private_includes, libiscsi_usr_public_includes], dependencies: kmod_dep, version: '0.2.0', c_args: genl_cargs, install: true)
Since meson created the shared libraries of the right name (and with the correct symlinks), I didn't dig deeper. But it turns out meson is setting the SONAME to "libopeniscsiusr.so.0"!
It also turns out I can manually set the SONAME in meson, so I *could* change the SONAME back to "libopeniscsiusr.so.0.2.0", but I don't think I want to do that. I think I was naming the SOLIB incorrectly before, and meson is doing it correctly.
So I will bite the bullet and change the name. If testing shows I can make it work. :)
Thank you again to everyone that replied!
If I understand correctly, you have decided to change the SONAME and the package name to "libopeniscsiusr.so.0" and "libopeniscsiusr0", respectively.
Correct.
I don't think this is a good idea after the previous package had "libopeniscsiusr.so.0.1.0" and "libopeniscsiusr0_1_0".
The previous version of this package (before meson) had "libopeniscsiuio.so.0.2.0" and "libopeniscsiusr0_2_0". Before that, with the previous library (a few years ago?), it was "libopeniscsiusr.so.0.2.0" and "libopeniscsiusr0_2_0". The question of the SONAME boils down to this: it should change when the APIs of the library change, as far as I understand. Indeed, going from 0.1.0 to 0.2.0, new APIs were added. So the SONAME needed to change (and it did). There are no new changes planned for the library, so it'll probably be 0.2.0 for a while.
I would recommend you stick to the same SONAME naming scheme that was originally used. So, if the ABI is still compatible and the SONAME changes was really just introduced by the switch to meson, you could just keep the previous SONAME "libopeniscsiusr.so.0.1.0". If the ABI is incompatible, switching to "libopeniscsiusr.so.0.2.0" makes more sense than switching to "libopeniscsiusr.so.0". In my experience, ".0" is usually just a lazy persons's SONAME, basically equivalent to saying "we are not tracking SONAME properly". It's true that the SONAME is just a string, but it's also being read by human beings, which tend to interpret it similar to a version number.
First of all, this is already pushed to the OBS and submitted to IBS. Second, I believe the correct SONAME should be "libopeniscsiusr.so.0", so I'd like to use that going forward. Of course that will change when (and if) the library APIs change again. Lastly, there are a lot of library versioning/naming schemes out there, and I hardly think using a single number is lazy. But in fact we do not use a single number here -- upstream chose the MAJOR.MINOR.SUB numbering scheme.
As others have suggested, the alternative would be switching to proper symbol versioning in the upstream library. But that would be an extra upstream development effort.
Yes, I have that on my list of things to do, but I'm not sure how to do it correctly. Right now, there is no definitive list of the APIs in the library except in the header file. So the build actually makes man pages from the header file. This way, if and when new APIs are added, it's all handled automatically. If I make a static list of the APIs it will add to the steps needed to be taken when adding a new API. But then again, as I said, new APIs are not common in this library. Still, I don't want to add more work. :) Bottom line I'll probably just make a static list for versioning the APIs, but I just haven't gotten to it. (Partly because nobody cares and it would have little actual benefit right now.) But please feel free to submit a pull request. :)
Martin