rpmlint warnings...

[Nathanael D. Noblet]

On 11/15/2009 03:05 PM, Michael Schwendt wrote:
> On Sun, 15 Nov 2009 22:30:44 +0100, Dominik wrote:
>
>> On Sunday, 15 November 2009 at 21:59, Nathanael Noblet wrote:
>>> Hello,
>>>    So I recently posted my first package and the review. While I waited I started cleaning up more issues I found after I realized you could run rpmlint on the actual rpm and not just the spec file. I'd like the review to go as quickly as possible so I'm just trying to get all those warnings cleaned up.
>>>
>>>    My package has a number of sub packages for various backend drivers. These subpackages basically contain a .so file for the most part however I'm getting rpmlint messages as follows
>>>
>>> libdspam.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libdspam.so
>>>
>>> how is libdspam.so determined to be a devel file?
>>
>> Shared objects (libraries) residing in %{_libdir} usually have names like
>> libfoo.so.X.Y.Z where X.Y.Z is their ABI version number. -devel subpackages
>> contain libfoo.so which is usually a link to libfoo.X.Y.Z and is used for
>> linking against libfoo (-lfoo in linker command line).
>>
>>> libdspam.so.7.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
>>>
>>> Is what I get back from file. What is it that I'm missing?
>>
>> Judging by the above, your libdspam.so should in fact be named
>> libdspam.so.7.0.0.
>
> It is. "file" prints the file name, not the SONAME.
>
> Often, projects, which dlopen plugin/module shared libraries at run-time,
> store the versioned libraries as well as the .so symlinks. Then they dlopen
> the libraries via the .so symlinks.
>
> Find out how and with what file names those backend libraries are loaded.
> If the .so symlinks are not needed, don't package them. And if the
> backend libraries have SONAMEs defined, check for [potential] conflicts with
> system libraries.
>

So I've grepped through the source a bit and the library loads a storage 
driver from the config file. So in the case of mysql the dspam.conf file has

StorageDriver /usr/lib64/dspam/libhash_drv.so

and passes that full path to dlopen. The sub driver package has the 
following files.
/usr/lib64/dspam/libmysql_drv.so
/usr/lib64/dspam/libmysql_drv.so.7
/usr/lib64/dspam/libmysql_drv.so.7.0.0


It will open the .so which is a symlink to the real file of so.7.0.0. I 
don't think it would be feasible to have the config file load the 
so.7.0.0 because any update to to the SONAME would cause a config change 
when it may not be necessary.

So in this case do I package them all? So does that mean the .so is okay 
to be in the non devel package?