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
