Fwd: Compat Libraries (was Re: libcurl.so.2) [mpeters at mac.com]

[Michael A. Peters]

On 12/07/2004 07:00:32 PM, Sean Middleditch wrote:

> 
> If the packages had just used a more intelligent naming scheme, this
> problem wouldn't exist, ever.  Name the packages libfoo1, libfoo2,
> etc.
> Get rid of the compat-foo stuff.  If you upgrade, libfoo1 stays
> around,
> libfoo2 is installed, no problems.  Ten years down the road (assuming
> the glibc/gcc gods don't decide to screw users over again and break
> tons
> of ABI) you can still install your apps that relies on libfoo1.

Assuming that libfoo2 and libfoo1 don't install conflicting files. This  
is the case with curl - both packages install a /usr/bin/curl binary.

Sure, you could separate out libcurl from curl and have curl depend  
upon libcurl, or you can just make a compat-libcurl package that  
installs alongside current curl and only provides an older version of  
the shared library. Ten years down the road you can still install that  
same compat-libcurl package, and maybe even have 3 or 4 other compat- 
libcurl packages installed right next to it. There is no problem with  
the rpm naming scheme. The only reason for calling it compat-libfoo  
instead of just libfoo is to make it easier for users. Note that there  
are several kernel packages all named kernel - all getting along.

There is nothing wrong with the current naming scheme, in fact, it is  
better for cases where MightyApp depends upon libfoo but builds against  
several different versions - then MightyApp just needs libfoo-devel to  
build and doesn't have to care about version in the name.

Oh - and it probably is better to rebuild the compat packages for each  
new release of the distro, rather than keep using the same 10 year old  
build. Not because you have to, but because if libfoo links against  
libbar, and succesfully builds against a new current version of libbar,  
then the user can have a compat-libfoo that uses current libbar and  
doesn't need a compat-libbar.

The less compat packages a user has to have, the better, because older  
versions of libraries are going to take the longest to be security  
patched because they are low demand and patches have to be back-ported.

When compat libraries are used, it should be understand the library is  
depricated and the compat library is provided as a convenience until  
your software is updated.