[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: packaging libraries with no versioned .so files



2009/3/19 Hans de Goede <j w r degoede 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)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]