[ On Friday, September 8, 2000 at 10:41:58 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: When DEPENDS can be upgraded in place
>
> On Fri, 8 Sep 2000, Tim Rightnour wrote:
> 
> > I think the real solution is to allow multiple versions of pkgs containing
> > libraries to coexist in some manner..  Ie..lets say I install jpeg...
> 
> I really don't like that...

It really is the only solution....  and it's not even that hard to get
right -- it's just a matter of coming to an understanding of what
requires what and when.

It's amazing (or NOT) that this discussion has come full circle to match
previous discussions of this issue.  

Not so long ago I posted an outline of a proposal describing just how
this could be done.....  (the basic idea was to split all packages that
install libraries and/or headers, etc. into run-time and development
variants and to allow multiple run-time versions to be installed
simultaneously)

> Even under a.out, the new binary would only continue to use
> libjpeg.so.1.0, if the binary was running when you upgraded. The next
> time you invoke it will load libjpeg.so.1.1.

Yup.

> Why do you even want old
> libraries hanging around?

because you will have bumped the major version....

> If the _major_ is bumped, the app will still load the old one, if it
> exists. If not, ld.so will emit an error, and it will try to use the
> lib with the wrong major, newer or older. That even works, sometimes.
> At least, that's how I remember it working on a.out.

As a package maintainer it is absolutely 100% necessary to always bump
the major number of the library for every upgrade regardless of whether
or not the new version is in fact backward compatible or not and any
package that depends on the library must depend on the new installed
version of it.  The available dependency maintenace tools are just too
dumb to allow this to work any other way.  It is not safe to use shared
libraries in this context to try and "fix" shared bugs -- the dependency
on the fix must be explicitly declared.

The trick of upgrading a shared library without changing the major
number is only suitable for an OS vendor who expects to distribute
patches to binary-only customers (i.e. without distributing full sets of
all binaries that use those libraries).

Even if the library vendor gives strong assurance that the API has not
changed this is not sufficient for a package because in order to get the
new library (a) installed and (b) used at run-time, the application
package must depend on a new version of the library package and the
application must link against a new major number of the new library.
(at least the latter is true if you do allow multiple versions of a
runtime library package to be installed simultaneously)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>