On Sat, 20 Oct 2001, Jason R Thorpe wrote:

> And, if we were to select your way, there could be significant, annoying
> pitfalls at "major release" time (nevermind that just defining what exactly
> constitutes a "major enough" release is an issue that we haven't even touched
> on yet), for what amounts to zero tangible gain.
>
> So, let's review:
>
> 	"Our way"	No significant overhead, maintains full ABI
> 			compatibility with all previous NetBSD releases.
>
> 	"Your way"	Chance of screwing over users[*] at upgrade time
> 			for basically no gain.

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 choice is pretty obvious to me.
>
> [*] We haven't even touched on the "no way to rebuild old app because
> vendor either doesn't exist any more, or source code for mission-critical
> app simply no longer exists".  I know of at least one NetBSD developer
> who was paid a good chunk of change to ensure this type of application could
> continue to run on an updated NetBSD system.

But there aren't we talking about a case where we aren't compiling said
program? As long as the pre-bump libraries are around (and their syscalls
are supported by the kernel), what is the problem?

> Anyway, I think it's safe to say that the current practice of doing
> symbol renaming for ABI versioning is not going to change, unless some
> better way of maintaining full ABI compatibility comes along.

I agree that the renaming we do is the best thing to do in general. What I
describe above strikes me as as much of a flag day as the a.out to ELF
transition was for i386. It'd be a real PITA.

It's just I expect there will come a day when we decide it's time to bump.
I'm not proposing what the criteria for that is (and I expect it is five
to ten years off), but I expect it will eventually come. Mainly as the
alternatives are: NetBSD's dead, or NetBSD has stopped making changes of
the type for which we do renaming now. The latter case strikes me as being
NetBSD has stagnated. As I hope neither of these things happens, I expect
the day will eventually come when we need to bump libc.

I'd also expect packages of the old (pre-bump) libraries would be
available in pkgsrc or in a pkg-ized base install.

Take care,

Bill