From Mandriva

In order to enjoy better upgrades, it is important to keep old major library versions in the system so that programs which use them still work.

Contents [hide] 1 Naming Conventions 2 Special cases 3 Provides and conflicts 4 An example

Naming Conventions

Libraries in /usr/lib, /lib and /usr/X11R6/lib must be separately packaged, in a library-only package, named with the name of the main library concatenated with the major of the library (or soname, see below). These packages should not contain any binaries, which should be in a different package. The goal is to be able to install libfoo1 and libfoo2 on the same system.

First of all, it is fundamental that the source rpms keep the same name without any major number, so that the CVS repository contains only one branch for each package.

When the distribution must have two versions of the same library at the same time (for example, qt1 and qt2), the sources rpms will be separated so that we can include both versions in the distribution as two different, independently maintained packages.

Here's a generic example: the following happens when the library comes with binaries, config files, or anything else that won't fit in the main library package (where only libraries go) nor in the devel package (where headers and devel libraries go (e.g. .so and .a)).

• Source package:
  • foo-2.3.4-4mdk.src.rpm

• Binary packages:
  • foo-2.3.4-4mdk.arch.rpm
  • libfoo2-2.3.4-4mdk.arch.rpm
  • libfoo2-devel-2.3.4-4mdk.arch.rpm

When replacing an existing foobar package with a new package libfoobar3, and foobar contains no binaries or configuration files, libfoobar3 should obsolete foobar. This is often the case for the more simple libraries.

• Source package:
  • foobar-3.1-7mdk.src.rpm

• Binary Packages:
  • libfoobar3-3.1-7mdk.arch.rpm
  • libfoobar3-devel-3.1-7mdk.arch.rpm

Special cases

We described the default policy for library packages, however some special cases can happen and must be handled using the brain:

• Remember to always check the soname of the libraries (objdump -x libfoo.so.1 | grep SONAME), because some sonames include the library version number, for example libfoo-1.2.so.4. In this case, the package should be named libfoo1.2_4-1.2.4-3mdk.
• Packages ending with a number should be handled by putting a "_" before the major, for example libfoo23_4-1.2-3mdk (in this case the soname would be libfoo23.so.4).
• It is not necessary to split each library in separate packages: if a package contains several libraries, the name would be built from the main library of the package. If there are problems keeping libraries in the same package, the package should be split.

Provides and conflicts

It is important to supply some Provides, for a number of reasons:

• Concerning the -devel package, most of the time the client app will only want to put libfoo-devel in the BuildRequires, without any version information.
• For compatibility with other RPM-based systems, it's important to provide the original (canonical) package name (as shown in the example below). It's important to understand that putting a Provides without the version information makes it impossible for later client RPM's to put a version information on dependencies, e.g. "Provides: foo-devel" is NOT enough, please use "Provides: foo-devel = 1.2.4-3mdk".

You should also add Conflicts in devel packages when they can't be simultaneously installed with -devel packages for the previous distribution release (this is often the case when the major changed, without renaming the headers).

An example

Here's an example of a specfile for a package with no binary and config files, so only library binary packages are needed. (Note that the spec file is not valid, it is only an example that shows how it works and to highlight the difference with a normal package.

%define name    gtkmm
%define version 1.2.4
%define release 1
%define lib_name_orig lib%{name}
# api is the part of the library name before the .so
%define api 1.2
# major is the part of the library name after the .so
%define major 1
%define lib_name %mklibname %{name}%{api}_ %{major}

Name:           %{name}

#(!) summary for SRPM only
Summary:        C++ interface for popular GUI library gtk+
Version:        %{version}
Release:        %mkrel %release

%description
#Full and generic description of the whole package. (this will be the SRPM
#description only)

#main package (contains .so.[major]. only)
%package -n     %{lib_name}

#(!) summary for main lib RPM only
Summary:        Main library for gtkmm 
Group:          System/Libraries
Provides:       %{name} = %{version}-%{release}

%description -n %{lib_name}
This package contains the library needed to run programs dynamically
linked with gtkmm.

%package -n     %{lib_name}-devel
Summary:        Headers for developing programs that will use Gtk--
Group:          Development/GNOME and GTK+
Requires:       %{lib_name} = %{version}
#(!) MANDATORY
Provides:       %{lib_name_orig}-devel = %{version}-%{release} 
#(!) MANDATORY
Provides:       %{name}-devel = %{version}-%{release}

%description -n %{lib_name}-devel
This package contains the headers that programmers will need to develop
applications which will use Gtk--, the C++ interface to the GTK+ (the Gimp
ToolKit) GUI library.

%post -n %{lib_name} -p /sbin/ldconfig
%postun -n %{lib_name} -p /sbin/ldconfig

%files -n %{lib_name}
# ..
# include the major number (and api if present) in the file list to catch
changes on version upgrade
%{_libdir}/lib-%{api}.so.%{major}

%files -n %{lib_name}-devel
# ..
%{_bindir}/gtkmm-config
%{_includedir}/*.h
%{_libdir}/*.so

More information on the library system in Linux can be found at http://www-106.ibm.com/developerworks/linux/library/l-shlibs.html.