>I'm confused. I've been catching up on this thread, and am puzzled about
>how bumping libc's version number will mess up users "at major release"
>time. It strikes me that the pain would happen not at upgrade time, but at
>compile time after the upgrade if the upgrade were done poorly.
>
>I understand why all the library major numbers have to be bumped at once.
>And I mean like in one CVS commit to both the main tree, the xsrc tree,
>and pkgsrc.
>
>But if we do that, and we provide both new and old versions of the
>libraries, where is the problem? Already-compiled programs will point to
>the old libc, and will be using libraries that point to the old libc. New
>programs will get built pulling in the new libraries, all of which point
>to the new libc. So where is the problem?

the users would also have to rebuild any libraries that got installed
via pkgsrc at the same time, otherwise you'd end up with, eg,
/usr/pkg/lib/libpng.so.1 linked against libc.so.12 while any new
applications built from pkgsrc would pick up libc.so.13.  the link
wouldn't fail (afaik), but when you ran the application, it would drag
in libc.so.13 and libpng.so.1, which would subsequently drag in
libc.so.12.  which would not be good.

bumping the major when you switch execution formats is better, since
you *can't* use, for example, an a.out library with an elf library,
but since there's nowhere to go from elf...

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."