guidelines, devel, .so, and dlopened files

[Hans de Goede]

Hi all,

Related to this, we currently have our Provides/Requires: namespace 
being poluted by automatic .so provides for files which are only meant 
to be dlopened aka plugins. The easiest fix for this would be for the 
autodep generator to only look in files which are in the ld.so 
searchpath (including those listed in ld.so.conf.d files in the 
RPM_BUILD_ROOT, to correctly handle things like qt3).

Any Thoughts / suggestions on this?

Regards,

Hans




Patrice Dumas wrote:
> 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
> 
> --
> Fedora-maintainers mailing list
> Fedora-maintainers at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-maintainers
>