guidelines, devel, .so, and dlopened files

[Patrice Dumas]

Hello,

There are some rules that seem to be followed in extras, regarding
devel packages, headers and .so, but are not in the guidelines, it 
would certainly make sense to discuss, explain and precise those.
There are specific packages that are exceptions and not concerned by 
those guidelines, like the libc, compilers, binutils, kernel...


First a definition: there are 2 kinds of shared objects, shared 
libraries that are loaded by the dynamic loader and dlopened object 
files that are loaded dynamically in the code. A library file may 
always be technically used both as a shared lib and a dlopened 
file, however in most cases it is used only as shared lib or as a 
dlopened file.


If a shared lib is named foo (linked with -lfoo), the name of the 
library file must not be libfoo.so. The convention is to name 
it according to its soname. This kind of library must have a soname.

If the shared lib is never dlopened, and there is no reason to rebuild 
something against that library (like for example for compat packages, 
or packages with only internal libraries) no link pointing to the 
library file with name libfoo.so should be shipped.

If there is no shared library nor program, only static libs and headers,
if the library depends on other -devel packages, the main package 
must be empty (and therefore not generated) and the library and headers
be in a -devel subpackage. If the library doesn't depend on -devel 
packages it is also possible to have everything in the main package which 
then must provide the corresponding -devel.

In the other cases, a -devel package must be split out of all the 
packages containing libraries. If there are headers corresponding with the
public API of the package it have to go in that devel package. Static
libs, if shipped must also go there, with autoconf macros, pkgconfig 
files, config scripts, programs used for code or headers generation... 

If the shared library is never dlopened, a link named libfoo.so 
pointing to the library file have to be shipped in -devel, and not 
in the main package.

If dlopened files are not used as shared libs, they mustn't be in 
any directory searched for by the dynamic loader, but instead in a 
subdirectory of %_libdir (or /%_lib). This is the general case for
things like plugins. Those dlopened files should be called like foo.so
and not have a version in the file name, for example they could be
generated by libtool with -avoid-version  -module (it is not a strong
requirement, it is just good practice).

There is a special case for libraries that are to be LD_PRELOAD'ed,
in that case they could be in the dynamic loader search path and they
may be named libfoo.so.

It seems to me that those rules are to be followed in all the cases, and
should be in the guidelines.


Now we come to a more controversial issue: libraries used as shared lib 
but also dlopened. In that case, my personal opinion is that there should
be 2 libfoo.so links pointing to the shared library. One should be in 
the -devel package in a directory searched for by the linker, and not in 
the main package. The other one should be in a subdirectory below %_libdir 
where the dlopening programs should search.


Thoughts?

I have justifications for some of the rules, but I think that some
people on the list know that subject better than me, so I'll let them
speak if there is resistance ;-)

--
Pat