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