I think the question is how long are we going to hang onto the cruft?

We're accumulating an alarming amount of detritus; I'd like to see it
cleaned up at some point. Whenever we migrate to a 2.x release might be a
nice time to declare that This Won't Work Anymore.

I comprehend why everything needs to be rebuilt.  The thing is that we
can't carry the world forever.  Well, we COULD, but I don't think it
would accomplish much.

And while we don't want to alienate the users, are we going to let ourselves
suffer technically for that end?

FWIW, I don't think Solaris is doing it "right", either.  I did some
hard thinking about this, and I can deal with updates for the stuff I
can't compile, and I can recompile the rest.

But that's just me.  ACtually, no, from the discussion I've seen, it
isn't just me.

# ELF has no way to do this -- I've already said why -- "libc.so.12" and
# "libc.so.13" are DIFFERENT LIBRARIES as far as ELF is concerned.
#
#  >   The reason *I* keep asking about the libc bump is because at some point we
#  > *will* have to do it. I'm not saying that it will be fun, or desireable, but
#  > the accumulated cruft will overcome the pain. Also, people doing certain
#  > restricted environments (where they do not have any dependancies) may like to
#  > get rid of the cruft.
#
# No, I don't believe we will HAVE to do it.

No, but what good is keeping the cruft around?  Eventually it's going to
get unwieldy.

# Note we are not the only system to note this problem/issue -- Solaris has
# had the same libc major number for ... a very long time, and uses a renaming
# scheme similar to the one we use in its libc.

What makes solaris' way "right"?  Declare a day of backward combatability,
move on and leave it at that.  It's gonna suck for a while.

It's gotta be technically better than growing a rename farm inside a
library.

And then we can forget about it for the NEXT five years.

#         -- Jason R. Thorpe <thorpej@wasabisystems.com>

				--*greywolf;
--
NetBSD: My Computer Runs!