Shaleh <[EMAIL PROTECTED]> writes: > Only if we are wrong. We should endeavor to do what the upstream > maintainer does unless it is flat wrong. We are not RH, maybe they > should make their sonames match ours. No, we should both do what is > right.
I definitely advocate following the upstream maintainer (although there are a few borderline cases, e.g. Imlib, which changed data structures between 1.2 and 1.3, but kept the soname the same.) My libgdbm.so.2.0.0 seems to be left over from some earlier version of the package - it's dated 1996 - I suspect it's a libc5 file that I manually installed during the fiasco with perl and bash moving to libc6. I don't know about the jpeg issue. Does the upstream maintainer advocate a soname of libjpeg.so.6a rather than libjpeg.so.6? What about ncurses? Does upstream use soname 3.0? I suspect that Red Hat kept the 3.0 soname for the latest libncurses because it is binary compatible with version 3.0. It would be difficult for either Red Hat or Debian to fix it at this stage in the game (both Debian and Red Hat could add symlinks to help with the problem, though), but an effort should be made in the future to prevent this from happening. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
