(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: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.dump -Lv libXXXX.so|grep SONAME
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 librariesIf 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