On Mon, 2009-12-21 at 15:31 -0600, Jon Ciesla wrote: 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. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

On Tue, 05 Jan 2010 22:24:22 -0500, Rich wrote: 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. 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. 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. 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. Why? For example, plugins/modules as well as LT_PRELOADed shared libraries don't need to begin with "lib".