On Sun, Oct 21, 2001 at 03:11:49AM -0400, Greg A. Woods wrote:

 > > And, if we were to select your way, there could be significant, annoying
 > > pitfalls at "major release" time
 > 
 > Can someone who thinks they know exactly what those pitfalls might be
 > please elaborate on them in enough detail to be convincing?

You're about to earn a special place in my procmail filter.  The arguments
that have been made (along with actual experience in the area) certainly
are convincing enough to those of us who make the decisions for the NetBSD
source tree.  The fact that you can't see past the nose on your face is
YOUR problem, not mine.

 > > (nevermind that just defining what exactly
 > > constitutes a "major enough" release is an issue that we haven't even touched
 > > on yet)
 > 
 > Of course not -- and unless users and developers alike explore the
 > relative risks and merits of _all_ of the options, it'll be impossible
 > to make such a definition too!

Actually, I'd venture to say that there isn't any release that's
"major enough" to constitute breaking the ABI.  If there ever were
such a "major enough" release, the "enough" would be totally artificial,
i.e. "major enough simply because we're arbitrarily deciding to break
ABI backwards-compatibility".

 > > for what amounts to zero tangible gain.
 > 
 > There seem to be several people who think there is something to gain.
 > 
 > One obvious issue is that the renames in use to maintain shlib ABI
 > backwards compatability are ugly and sometimes confusing cruft.  We do
 > many things on many levels to maintain compatibility with historical
 > interfaces.  The point here is that there's a relatively simple and
 > painless way to get rid of some of this cruft.

This is not a convincing argument.  There are not of things in an operating
system that can be confusing to people not familiar with them.  Just because
some new hacker doesn't understand the details of how the virtual memory
system works, does that mean we should delete VM?  Indeed, VM systems can
be quite complicated to maintain.  By an extension of your argument, we
should delete it.

 > Indeed didn't you yourself post something suggesting that you had wanted
 > to get rid of some __RENAMEs in the aout->ELF transition?  Why would you
 > have wanted to do that if there was no tangible gain to be had from
 > doing it?

I did ... but I changed my mind after discussing it with several other
very experienced developers.  Esp. when it was pointed out that you can't
simply use the presence of __ELF__ to determine if the rename should be
deleted from the source, since some ports have been ELF from the beginning.
Also, what happens if you need a rename later on in the game, after the
ELF transition happened?  Stop and think about what is easier to maintain:

	* A renamed symbol that everyone uses.

	* A renamed symbol that is used for a.out, plus some ELF
	  platforms, or maybe all platforms after a certain date.

I.e. "no #ifdefs" vs "potentially long list if #ifdefs".

 > Personally I think the largest gain will be to the developers
 > themselves, with fallout that affects the overall quality of all the
 > code in the system as a whole.

Nice for you to be thinking of us.  Now think a little harder about what
the developers will have to go through if there's even the tinyest botch
in the major number bump process.  Some of us HAVE BEEN THROUGH THIS BEFORE,
and experienced SIGNIFICANT PAIN due to a libc major number bump, which
is why we are still at libc.so.12.  So, since you seem to be so concerned
with the well-being of us developers, I strongly suggest that you think
a little more about your position on this issue.

 > Since "my way" hasn't even been defined in any detail yet it's
 > impossible for you to evaluate it.  Indeed your attempt to claim that
 > there might be a chance of "screwing over users" suggests you too have
 > failed to read all of what I've written and to fully understand what
 > little I've proposed so far.  I have not ever suggested that users of
 > third-party dynamic linked binaries _must_ be left out to hang -- quite
 > to the contrary I've discussed the options they have and the options
 > that NetBSD can offer to alleviate their suffering.

Your proposed "solution" only suggests to me that you simply fail to
fully understand the problem.

In any case, as far as I'm concerned, this "discussion" is over.

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