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.
