shared library SONAME about sg3_utils HOT 2 OPEN

libsgutils2 is intended to be public library but was not designed as such. Initially it was to save me duplicating code in each sg_* utility. I try not to change the interface of existing functions but sometimes T10 makes that difficult so I might add a <function_name>_v2 variant. I think more about multi OS support, C and POSIX compliance than ABI stability. Plus I check it builds cleanly in C++ .
I have noticed that runtime linking with shared objects can fail if a utility from version 1.45 say (e.g. sg_vpd) is run with the libsgutils2 from version 1.44 .

I'm no expert on SONAME and libtools but will take some guidance from the downstream RedHat and Suse maintainers if it can be improved. To date I don't remember getting any feedback from them on this issue.

from sg3_utils.

I have noticed that runtime linking with shared objects can fail if a utility from version 1.45 say (e.g. sg_vpd) is run with the libsgutils2 from version 1.44 .

That would be expected, I think.

Debian wants to ship libsgutils2 (and currently does), because other software uses it. With the current SONAME format, everytime there is a new sg3_utils release, the SONAME changes. This causes a lot of work on the Debian side (new binary packages have to be introduced, all software using them has to be rebuilt, etc). Which is not ideal. BUT: if you are saying you do not have strong ABI stability checks in place, then maybe this is correct (for now)!

It really depends on what you want to do. If you can commit to ABI stability (and: if the ABI changes, changing the SONAME), then a manually managed, "stable" SONAME is a good thing. On the other hand, if the ABI can change maybe unexpectedly, then its better to keep the version number in the SONAME.

from sg3_utils.