[svlug] packages v. tarballs (was manners)

Rick Moen rick at linuxmafia.com
Sat Jun 30 18:10:02 PDT 2001

begin  Joey Hess quotation:

> Saying that package naming is at issue is perhaps a debian-centric
> statement. After all, rpm should allow you to install multiple
> versions of the same library package.

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?

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

>> It's conceivable that I might want to run some binary dynamically
>> linked against soname "libc.so.2.1"
> That would be difficult, as there has never been a version of glibc
> with that soname. 

Entirely possible, but rather beside the point I was trying to make.  (I
didn't remember precisely which versions of the glibc 2.x / libc 6.x
family I've had:  The point was to illustrate the general concept of
multiple versions of a library, some old and some new, possibly
continuing to be useful.

> That's glibc 2.2.3. Well, perhaps there was a soname libc.so.2 way
> back when, but a libc.so.2.1? Never. Sonames should not encode minor
> revision numbers of libraries (of course, that is ideal; in reality I
> probably have 10 libraries installed with a minor revision number in
> their soname). There is a nice screed about this in libtool's info
> file, I think.

And I will probably overcome my anitpathy to the info format, and the
inertia that stands in the way of my making it accessible using
reasonable tools, long enough to read it.  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.  Even
as it was, the newsgroups were full of Red Hat users with their 5.3.18
(or whatever) libraries, wondering what was preventing the app from
launching.  Having the binary invoke soname "libc.so.5" would _not_ have
been an improvement.

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

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. 

> Of course if a packaging system can't somehow deal with installing
> multiple versions of a lib that have different sonames, it is indeed
> broken, but I suspect that all but the crummiest can.

I think that any of them can _if_ the versioning is included in the
library's package name.  My point is that it almost never is.

> If this sort of breakage happens regularly, should the packaging
> system allow admins to work around it retroactively by easily
> installing multiple minor releases of the same library?

Well, I think it should.  I'd like to be able to put a particular
version of a library on something similar to status "hold" (don't remove
this) for the benefit of something like StarOffice 4, and then _still_
be able to also install later versions of that same lib.  This is the
flexibility that is granted to me by the ld-linux.so, the soname system,
and library versioning.  Why should a package system stand in the way of
my exercising it?

Cheers,                                            Rehab is for quitters.
Rick Moen
rick at linuxmafia.com

More information about the svlug mailing list