(This page is a bit short right now, but may accumilate more tips in the
future)
Upgrading, with dependancies
One pitfall that package maintainers must be aware of, when creating
packages of shared libraries, is the dependancy problem. Unlike simple
"provide an executable" packages, your package has other packages that
may depend on a specific version of the bits in your library package.
If only your own packages depend on your shared library package, you
can probably manage things yourself. But when you maintain something
used by 10 other peoples' packages... how can you safely release
an update?
Sometimes, no changes are neccessary. This happens when the newer version
of the library is completely compatible, and also the "SONAME" matches.
You can find the SONAME, by doing the following:
dump -Lv libXXXX.so|grep SONAME
Unfortunately, you will eventually have to deal with the case where
the newer version of the library has a different SONAME than the
older one.
If there are only a handful of package, it is often possible to
work with the other maintainers, and temporarily install the newer
version of a library on our build machines, so that the other maintainers
can recompile. Your library package, and their dependant packages, should
then be released together.
For more than that, it is usually neccessary to include older versions
of a library, in your package. So, if you are releasing
libfoo.so.1.3, it is appropriate to copy in the older libfoo.so.1.2
into your package.
In this manner, you can provide an updated version for people to compile
against, while also not breaking existing packages, until their maintainers
have time to recompile.
How can you know, when everything has safely been recompiled, and you
no longer need to include the older shared library?
Put the "SONAME" of the library, into our
search page. For example, currently,
putting in "libssl.so.0.9.7" will give you a fairly long list of
packages that depend on that specific library provided by our
openssl package.
Optimized libraries
If there are speed benefits for compiling a library for a more recent
cpu/architecture than our defaults, you may choose to provide both generic,
and highly optimized versions of shared libraries.
Usually, you can then ship both versions of the library in a single package,
by taking advantage of the ISALIST feature of the dynamic linker.
Properly compiled programs will then automatically take advantage of the
"best" library to use, on the current machine.
See our page on isaexec for more details .
