Under no cicumstances the unversioned library should be shipped in Fedora.

This is a new requirement that is not in our current guidelines. Do we really want to require that? There are cases where versioning the library is not necessary at all (e.g., if it is only used by the same package, or other subpackages built from the same SRPM).

Replying to [comment:1 kkofler]:

Under no cicumstances the unversioned library should be shipped in Fedora.

This is a new requirement that is not in our current guidelines. Do we really want to require that? There are cases where versioning the library is not necessary at all (e.g., if it is only used by the same package, or other subpackages built from the same SRPM).

The trouble with unversioned libraries is that if user builds his code against unversioned library, and than we ship newer version (with possible ABI incopatibilities), some hard to trace bugs & crashes might start to occur, and it may take a while to find out that the library update is to blame and the code needs to be rebuilt. With versioning, the program refuses to run with error explaining that it misses the previous version library and the problem is much easier to pinpoint and solve.

Personally, I think that requiring the versioning of the library saves us many future bugzillas from confused users about their code mysteriously starting to crash after some innocent-looking library updates.

At today's meeting I was a little unsure but I think the other FPC members generally like this. We'd like some clarifications:
Reading the draft, I think some maintainers will confuse the SONAME with the filename. Probably should say somethings to differentiate this.
* Maybe information about getting the SONAME? (objdump -p |grep SONAME ?)
How does the version interact with the dynamic linker?
* I assume that this is going into the ELF SONAME field. Does the linker parse major minor micro from that field or treat it as one big string?
* Does the linker attempt any sort of "this version is compatible with this other version" check or does it simply do an equality check?
* In addition to the gcc linker flags we should probably also have an example of changing a libtool-driven build to pass in the right SONAME.

Note: I think I got confused during the meeting. My assumption is that the linker treats SONAME as one big string and compatibility is checked via an exact match between DT_NEEDED in one object and SONAME in a library. If that's so then I agree with geppetto and tibbs that libfoobar.so.0.n should be sufficient.

tibbs also mentioned recommending libfoobar.so.0.0.n in the past. I'm not sure if he thinks extra version number is something we should recommend.

I added a section explaining what soname is and how to read and write it. To prevent future confusion, it also contains answers to the other asked questions. In short:

• AFAIK the dynamic linker simply checks for equality, that is the reason the version should be bumped after discovering ABI or other compatibility problems.
• The gcc and libtool both supports (according to their manpages) the same flags in this regard, so I assume it will work with both of them. However I never used a libtool, so I might be mistaken.

As for the name, trouble could arise if the upstream starts the versioning before final release and also uses the .0.n scheme for pre-release builds. However, as this guide should be used only in the case the upstream is unwilling to version the library, it should not be problem. On the other hand, it might not hurt to consider this in advance and use the .0.0.n scheme, which is less likely to interfere.

info the revised Downstream .so versioning draft Approved (+1:6, 0:0, -1:0)

We didn't find the libtool section enlightening so we removed it. We would like something there. But we decided we're willing to go with what we have for now. If someone asks how to do this for an autotools driven project then we'll add a recipe at that time.

So, these just need to get written up? Added to the guidelines somewhere? I'd also suggest a link from http://fedoraproject.org/wiki/Common_Rpmlint_issues#no-soname

Announcement text:

Added information on dealing with unversioned shared libraries: https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning