packaging libraries with no versioned .so files

Hans de Goede j.w.r.degoede at hhs.nl
Sun Mar 22 09:13:43 UTC 2009


Nicolas Chauvet wrote:
> 2009/3/19 Hans de Goede <j.w.r.degoede at hhs.nl>:
>> Alex Lancaster 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.  It seems to make more sense to actually
>>> remove the -devel package and include them in the main eclib package.
>>>
>>> The guidelines don't appear to cover the case of packages that only
>>> consist of unversioned .so's.  Ideally upstream would add the
>>> versioning, but currently don't support versioning the library.
>>>
>>> Either way, I would like to know what the best practice would be in
>>> this case, and ultimately it would be useful if there was an explicit
>>> guideline.
>>>
>> If upstream doesn't do library versioning it is a safe bet that they
>> don't guarantee ABI stability either.
> Another possibility is that this library is meant to be dlopened.
> That was the case with yafray which is a image renderer for blender.
> When i've patched it to use a SOVERSION and moved the symlink to a
> -devel subpackage,
> then it used the binary as a fallback method to talk to the image
> render which disabled lot of features.
> 

If it is a plugin it does not belong directly under %{_libdir}, but should be in
a subdir of it, and having unversioned .so files in subdirs is fine (as  long as they
do not get added to ld.so's search path.

Regards,

Hans




More information about the fedora-devel-list mailing list