On Mon, 2009-12-21 at 15:31 -0600, Jon Ciesla wrote:

...

• Libraries which are used by other programs at runtime should be

versioned, and in %{_libdir} -- Are there exceptions to this? When is it appropriate to leverage subdirectories and /etc/ld.so.conf.d/?

How so, by adding a path to /etc/ld.so.conf?

At least the MPI packaging guidelines are an exception to this one: the libraries are placed in MPI flavor specific directories, e.g. %{_libdir}/openmpi/lib, which should not be visible to programs by default. Instead, it is the environment module that sets the relevant environment variables to make the libraries and runtimes usable.

On Tue, 05 Jan 2010 22:24:22 -0500, Rich wrote:

I went ahead and created a set of draft guidelines for discussion, located at https://fedoraproject.org/wiki/PackagingDrafts/SharedLibraries

I tried to go by common practices, what the FHS states, etc. Let me know if I've missed the mark on anything or left something out.

Much too vague/ambiguous, especially for newbie packagers, who feel clobbered by the current guidelines already. It is increasingly difficult to create guidelines that simply say "do this" or "don't do that" without giving a clear but long rationale that covers corner-cases even.

| If a library is providing resources that other packages may need at | compile or runtime,

The difference between compile- and runtime is important enough not to cover both in the same sentence. Also, what "resources" do you refer to here?

| it should be installed directly to the default | library search path.

Why? And why "the default"?

| Wherever possible, these libraries should be created with versioning in | the filename,

Vague.

| and provide a set of unversioned symlinks in a -devel file.

This adds confusion. It is perfectly valid for a library to be called libfoo-0.10.so.0 with a libfoo-0.10.so symlink.

| In the case that a package only contains unversioned libraries, they | may be included in the non-devel base packages.

Insufficient for a general guideline. See further below in this mail, too.

| If libraries are installed into a subdirectory and do need to be on the | system library search path, an entry in /etc/ld.so.conf.d/ may be created | to add a subdirectory to the ld search path

If at all, there could be a future section on documenting ld.so.conf usage a bit more. Adding library search paths that way effectively makes the libs available to the run-time linker prior to searching in the trusted default paths.

| Libraries in %{_libdir} subdirectores do not need versioning in their | filenames.

But of course they do, if you add them via ld.so.conf.d entries. "ldconfig -vp|less" The filename is not so important. A library's SONAME is.

...

...

I've been gathering bits and pieces of information regarding the packaging of shared libraries for a while now. As I understand it:

• Normal .so libraries with versioned filenames go into the base package

for a program when they exist

Yes.

...

• Unversioned .so libraries go into the -devel package

Yes.

It cannot be answered with a plain "Yes", because such .so files may be plugins/modules loaded at run-time. Several package submitters have mispackaged such files because somebody told them that .so would need to go into -devel packages.

...

...

-- If there are no versioned libraries for a program, should a versioned library be added or should the unversioned .so file be included in the base package?

Option B, I think, but someone else with more insight should chime in. . .

The question is too vague. Does it refer to system libraries? And does "version" refer to a number in the library SONAME?

Typically, you cannot make up your own versioned library SONAME without creating incompatibilities. As long as the program authors don't use the same SONAME together with a sane library versioning scheme, you would run your own show. There are approaches that increase the package maintenance requirements and add incompatibilities, such as building from a libfoo.so (or libfoo.a) a libfoo-VERSION.so.0, which would require a modification of any app that linked with plain -lfoo and now would need to link with -lfoo-VERSION. Contact upstream. Though, it may be that they even refuse to apply a patch for building a proper shared library, because they want to continue with changing the API even in minor releases.

...

...

• Libraries which are used by other programs at runtime should be

versioned, and in %{_libdir} -- Are there exceptions to this? When is it appropriate to leverage subdirectories and /etc/ld.so.conf.d/?

Note that it may be that the upstream distribution does that by default. It's convenient for any library stack you would want to swap out at run-time (and with avoidance of file conflicts at install-time). Think "alternatives" for libraries. Multiple builds of a library with the same name but different build options or different releases.

...

...

• Libraries which are plugins to one specific program, and are dlopened

by that program, do not need a versioned filename. They should go in their own subdierctory in %{_libdir} (e.g. /usr/lib/gstreamer-0.10) -- If packaged as seperate plugins, they should be in packages called packagename-plugins-pluginname, or something similar

• All shared library filenames should begin with lib

Why?

For example, plugins/modules as well as LT_PRELOADed shared libraries don't need to begin with "lib".