Request for Guideline Clarification

[Rich Mattes]

Hi all,

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

- Unversioned .so libraries go into the -devel package
   -- 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?

- 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/?

- 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

A lot of this isn't in the packaging guidelines, I think if these points 
could be clarified and included in the guidelines it would help to 
answer a lot of questions.

Thanks,

Rich

[Jon Ciesla]

> Hi all,
>
> 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.
> -- 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. . .
> 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?
> 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
> A lot of this isn't in the packaging guidelines, I

think if these points
> could be clarified and included in the

guidelines it would help to
> answer a lot of questions.

If you like, you can write up a draft, and post here, or submit to the
FPC.

https://fedoraproject.org/wiki/Packaging:Committee
> Thanks,
>
> Rich

--
> Fedora-packaging mailing list

[e-mail]
>

https://www.redhat.com/mailman/listinfo/fedora-packaging
>

[Susi Lehtola]

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.

[Rich Mattes]

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.

Rich

On 12/21/2009 04:31 PM, Jon Ciesla wrote:
> > Hi all,
> >
> > 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.
> > -- 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. . .
> > 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?
> > 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
> > A lot of this isn't in the packaging guidelines, I think if these points
> > could be clarified and included in the guidelines it would help to
> > answer a lot of questions.
>
> If you like, you can write up a draft, and post here, or submit to the 
> FPC.
>
> https://fedoraproject.org/wiki/Packaging:Committee
> > Thanks,
> >
> > Rich
> >
> > --
> > Fedora-packaging mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-packaging
>
> -- 
> in your fear, seek only peace
> in your fear, seek only love
>
> -d. bowie
>
> --
> Fedora-packaging mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-packaging

[Michael Schwendt]

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".