On Sun, Dec 07, 2003 at 01:39:10PM -0500, Greg A. Woods wrote:
> [ On Saturday, December 6, 2003 at 20:02:38 (-0600), Eric Haszlakiewicz wrote: ]
> > Subject: Re: NetBSD 2.0 release date
> >
> > 	I believe the problem is that (almost) all libraries have an _implicit_
> > dependency on libc.  This means that the particular version of libc that
> > actually gets loaded at run time is controlled by what the final binary
> > is linked against.  Say you have binary foo, linked against libbar.1.
> > Both of those were linked against libc.12.  Now go rebuild libbar using
> > libc.13.  Since the libbar major version hasn't been bumped the binary
> > foo will continue to use it, but the wrong version of libc will be used
> > causing the code in libbar that was compiled against libc.13 to likely
> > break in various ways.
> 
> You are concocting a situation that will not occur, by design.
	Well, duh!  we're discussing which design to prevent the situation
is best.  I was describing the problem that is being solved.

> As has been discussed numerous times in the past it is expected that all
> shared libraries supplied with the system will have their major version
> numbers incremented and that the old versions will remain available for
> old binaries.  All vedors of proprietary shared libraries will also be
> made well aware of the fact that they must also provide their users with
> new shared libraries with incremented version numbers.
	That's a problem.  Bumping _all_ the major number of every single
library sucks.  It's way too much coordination and opportunity for mistakes
to happen, and when a mistake does happen you're not guarateed an immediate
and obvious failure.  Bumping the version of the libs certainly solves
the problem of mismatched libc version dependencies, but it's not a
good solution.  It can't be done incrementally, there's no way to 
prevent a earlier major version of a library from being built aganst
the new libc, and the failure modes are likely to be subtle inconsistencies
when any problems should be obvious and dramatic.

> However since most NetBSD users will either use pre-built packages from
> one consistent source (in which case they will have no worries) or they
> will rebuild programs from source (in which case these issues need only
> be considered during the recompilation and relinking of a new shared
> binary).
	you're assuming that everyone will install from scratch, or remember
to rebuild absolutely everything they have installed, and not accidentally
install an older library sometime later.  That's complete *bullshit*.  You
might think you're perfect at doing things like that, but most people aren't.
I certainly don't rebuild everything at once.  I do it a little bit at a
time, when I have the time to.

> In the latter case the issues are no different than they are for static
> libraries.  Linking a program with an "old" library is not guaranteed to
> work.  There is no simpler or more obvious rule and even the most naive
> user will understand it and accept it.
	You got that completely backwards.  The problem I was describing was
with linking a program with a _NEW_ library.  That _IS_ supposed to
work if the new library has not had a major version bump and the versions
of the libraries that that library and the program depend on are compatible.
(i.e. respective dependencies have the same major version)

> >  The fact that the old libraries are still installed
> > actually works against you here: programs will run even though it is
> > dangerous for them to do so.
> Actually no, it won't.  There will only be a problem if the kernel ABI
> has changed in a non-backwards compatible way, and provided the COMPAT_*
> options are maintained, there will be no problem for old binaries.
	the kernel ABI isn't the issue.   The kernel ABI has absolutely 
nothing to do with this.  We're talking about the C _library_.
Bumping the major version of the library implies that the library _API_
changes in a non-backwards compatible way.

> > 	If there was an explicit dependency in the library then this could 
> > be caught by ld.so and it could refuse to run the program.
> 
> Timestamps are quite sufficient.  All libraries must be re-compiled
> before new programs are linked with them.  A system upgrade procedure
> need only check that no libraries (static or shared) have timestamps in
> the future.  The linker need only check that no library has a timestamps
> prior to the system upgrade.
	ah yes, the magic "I-can-automatically-figure-out-when-an-upgrade-happened"
linker.  Running on a system where the timestamp of library files always
matches the time that they were built.
	oh yes, I forgot, in a world where no one compiles stuff on an earlier
release of the system after anyone has compiled stuff on the newer system.
Timestamp are far from a robust way of checking version compatibility.

eric