From Fedora Project Wiki
No edit summary
Line 12: Line 12:
The ''n'' should be the number of downstream release. Do not forget to add the <code>-Wl,-soname,libfoobar.so.0.n</code> to the compiler flags in order to compile-in the library name.
The ''n'' should be the number of downstream release. Do not forget to add the <code>-Wl,-soname,libfoobar.so.0.n</code> to the compiler flags in order to compile-in the library name.


When new version of the library is released, you should use the '''abi-compliance-checker''' tool to check differences in the build shared libraries, and if it detects any incompatibilities, bump the ''n'' number.
When new version of the library is released, you should use the {{package|abi-compliance-checker}} tool to check differences in the build shared libraries, and if it detects any incompatibilities, bump the ''n'' number.

Revision as of 15:16, 11 March 2014

Downstream .so name versioning

In case the upstream ships unversioned .so library (so this is not needed for plugins, drivers, etc.), the packager MUST try to convince upstream to start versioning it.

If it fails due to unwilling or unresposive upstream, the packager may start versioning downstream, but this must be done with caution and ideally only in rare cases, as the upstream version is the prefferd way. Under no cicumstances the unversioned library should be shipped in Fedora.

For downstream versioning, the name should be composed like this:

libfoobar.so.0.n

The n should be the number of downstream release. Do not forget to add the -Wl,-soname,libfoobar.so.0.n to the compiler flags in order to compile-in the library name.

When new version of the library is released, you should use the Package-x-generic-16.pngabi-compliance-checker tool to check differences in the build shared libraries, and if it detects any incompatibilities, bump the n number.