[svlug] packages v. tarballs (was manners)
joey at kitenet.net
Sat Jun 30 19:02:02 PDT 2001
Rick Moen wrote:
> You're the packaging expert, but I didn't think it did. The glibc RPM
> is named "glibc". If I try to install a new version, the old one is
> going to get removed. Am I missing something, here?
Just that rpm generally allows installation of multiple versions of any
package. Behavior is a bit undefined(?) if they contain files with the
same names, but luckily that is not the case with multiple versions of a
library. (This is also why rpm puts doc files in /usr/doc/package-version/.)
> > Debian is the one that conflates package name and version to
> > occasionally allow multiple versions of the same package to be
> > concurrently installed (but only if the maintainer of the package sees
> > a need beforehand).
> Yes, quite. I've notice this occasionally, most recently in the python2
> packages. But not often.
I notice it more often than I would like. :-/
> But I find it difficult to
> believe that there's some truly compelling reason to _never_ specify
> a minor version in dynamic calls to sonames: Consider StarOffice 4.
> Now, I don't remember what ldd reported for that binary, but they'd
> have been foolish _not_ to specify "libc.so.5.4" as the soname, since
> the application would work only with 5.4.44, 5.4.45, and 5.4.46.
Well, I could be wrong, but I don't think the dynamic linker works that
way. When it sees a program wants a library with a particular soname, it
means that _exact_ (letter-for-letter) soname. It's not going to try to
guess that a program's request for a soname "libc.so.5.4" can be
satisfied by a library that declares its soname to be "5.4.45" or
whatever. Those are two different sonames, and it has no way to tell
that something major has not changed in between, and it's not going to
try to guess at what sort of version number formatting is being used.
And this is, of course, one very good reason to _not_ encode minor
version numbers in the soname. If you change those minor numbers at all
frequently, you have in fact, changed your soname, and it's just as
painful as if you had changed the major number of the soname.
> > I look at this differently. If upgrading to the new versions of all
> > the libraries gnucash uses causes any other programs on the system to
> > break, then those programs are broken (for relying on undocumented
> > library features), or the libraries are broken (for changing something
> > without incrementing the soname).
> Maybe it _did_ increment the soname. Maybe libfoo went from
> libfoo.so.3.x to libfoo.so.4.x, with soname changes (and symlink chages)
> to match. Any binary that still attempts to invoke soname libfoo.so.3
> will be SOL -- because the system pulled that library out from under it.
That would be a fault of the packaging system (and/or the packaging)
> Now, at the moment, I can afford to be personally smug about such
> breakage elsewhere, because I'm not running any software outside the
> package system at the moment (let alone binary-only), but might want to
> do so. I guess I'd just have to assure ongoing presence of any needed
> libs outside the package system, as well.
I hope not. Any packaging system that pulled older major revs of
libraries out from under you would be broken (and I don't think any of
the major packaging systems will, though there might well be a rogue
frontend to one of them that does -- and I certianly have all my systems
configured so it at least _asks_ if it can remove this old version of a
library when I install a new major rev and no packages use the old one).
see shy jo
More information about the svlug