packaging libraries with no versioned .so files

Nicolas Chauvet kwizart at gmail.com
Thu Mar 19 10:31:00 UTC 2009


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.

At this time, it wasn't possible to dlopen from a versioned shared
object.. I think it is nowadays ; despite it still doesn't make sense
in the yafray case. (as in no case, any blender component are meant to
be linked with the yafray library).


Nicolas (kwizart)




More information about the fedora-devel-list mailing list