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

[Michael Schwendt]

On Wed, 08 Dec 2004 05:11:03 +0000, Michael A. Peters wrote:

> 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.

And 3 or 4 corresponding compiler toolkit chains, too, because you
need to maintain ABI compatibility with the ten years old platforms
and not just provide old libraries.

> 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.

In the days of package dependency resolvers, who decide for you from
where to take a needed library, the package name doesn't matter much.

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3
loadavg: 0.00 0.05 0.09