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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
