[packagers] Shared libraries in RPMforge packages...
mok at bioxray.dk
Tue May 15 17:27:17 CEST 2007
I want to point you attention to the way shared libraries are being
packaged in RPMforge. I think it is necessary to rethink the policy (if
there is one ;-) ). The problem is illustrated by the following example:
A few days ago, there was an update to the openexr package, which was
version 1.3 before, and is 1.4 now. The new package of course wants to
upgrade the older package, since 1.4 > 1.3. The NEW package contains:
... and more programs...
... and more shared libraries...
The OLD package contains:
When the NEW package replaces the OLD package, it wants to remove the
shared libraries version 3. However, I have a bunch of (local) packages
installed that depend on the OLD shared libraries, and apt-get therefore
wants to uninstall those.
This behaviour is not desirable, and is a packaging bug IMHO. The
openexr package -- and probably others -- need to split into several
subpackages. There is no reason that /usr/lib/libHalf.so.3 and
/usr/lib/libHalf.so.4 could not live next to each other (in the old and
new packages resp.). But this requires that the files that clash -- (in
this case the binaries) must be in their own package.
The solution to the problem is the following:
When the major number of a shared library changes, it is necessary to
change the name of the package. The obvious choice is to append the
major .so number to the package name, i.e. openexr4. You need to have 3
packages for this to work: one with programs (openexr4), one with shared
libraries (openexr4-libs) and one with header files and some of the
The binaries package (openexr4) depends on openexr4-libs, and replaces
the binaries in the old package (openexr3). Thus, in the upgrade,
openexr4 will pull in openexr4-libs. However, openexr3-libs will be
allowed to remain on the system, like it should if other programs or
packages depend on it.
Programs that need to use the openexr4 libraries, need to contain the lines
in the spec file. But openexr4-devel need to be able to coexist with
openexr3-devel, so their header files need to be in separate directories
(for example /usr/include/openexr3/ etc.). I may still wish to be able
to compile programs that need openexr3-devel to compile. And the
libraries will still be there, since openexr3-devel depends on
We have to assume that people:
1) Can have locally built binaries that depend on shared libraries.
These should not disappear overnight without a warning since it may
break the locally compiled software.
2) Can have locally built RPMs that rely on certain shared libraries.
3) May still want to develop programs using the old version headers and
link to old libraries, so the development environment should coexist
with programs using the new version.
This is in fact another variation of the infamous fftw discussion that
we have been having ad nauseam (thanks to yours truly ;-)). Fedora and
friends like to keep the generic name for the new package and provide a
*-compat package containing the old stuff. I intensely dislike that
approach; a package with a certain software version should never be
renamed. In the fftw case, RPMforge correctly bumped the package number
to fftw3 (but Fedora didn't).
I propose that RPMforge et. al. adopt a policy along the lines sketched
out in the above, so men and fish can coexist peacefully.
Morten Kjeldgaard, Asc. professor, Ph.D.
Department of Molecular Biology, Aarhus University
Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark
Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178
Home +45 86188180 * http://www.bioxray.dk/~mok
More information about the packagers