packaging libraries with no versioned .so files

Michael Schwendt mschwendt at gmail.com
Thu Mar 19 07:41:58 UTC 2009


On Thu, 19 Mar 2009 00:14:43 -0700, Alex wrote:

> Hi there,
> 
> The packaging guidelines:
> 
> http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
> 
> recommend that unversioned .so libraries should go into a -devel
> package. I'm reviewing a package, eclib, that has no versioned .so
> libraries at all:
> 
> http://bugzilla.redhat.com/show_bug.cgi?id=476398
> 
> To satisfy the review requirements submitter put the .so into a -devel
> package and suppressed the main eclib package, as there are no
> versioned .so to package. 

*sigh*  Happens regularly.

What matters is _when_ these .so files are used, not what their name is.
For an ordinary shared library with a versioned SONAME stored in its
header, the .so file is just a symlink, which is needed only when
compiling software. Very roughly, a linker argument such as "-lfoo"
resolves to adding either "libfoo.so" or "libfoo.a".

If, on the contrary, the .so file is the main library, it would also
need to be present at run-time. In run-time linker's search path, if
applications are linked with the library directly. Or in private paths, if
the library is some kind of plug-in, which is opened by the application
itself.

> It seems to make more sense to actually
> remove the -devel package and include them in the main eclib package.

True.
 
> The guidelines don't appear to cover the case of packages that only
> consist of unversioned .so's.

So far it is being assumed that packagers and/or reviewers know what they
are doing. For anyone else it's a pitfall.

> Ideally upstream would add the
> versioning, but currently don't support versioning the library.

Why? Because the API is not stable? It would be better then to include a
library version [or patch-level] into the library SONAME. That way,
library updates [accompanied with proper SONAME updates] would require
dependencies to be rebuilt/relinked.




More information about the fedora-devel-list mailing list