Subject: Re: src/gnu/usr.bin/egcs/common
To: None <tech-userlevel@netbsd.org>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
List: tech-userlevel
Date: 12/18/1999 14:37:28
>>>>> "Chris" == Chris G Demetriou <cgd@netbsd.org> writes:
    Chris> "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca> writes:
    Chris> What we _would_ need to do is bump the major number of every
    Chris> shared library that depends on libc, or else incompatibilities
    Chris> would result.  That's not just fun, it's pretty much intractable.
    >> 
    >> Yes, we would have to do that.
    >> 
    >> But, not if we provide a non-threads libc.so.12.X that was compatible with
    >> the old code.

    Chris> And, what does that buy you?  if you're going to bump the major
    Chris> number, why not just ship the last of the old line of libc's in the
    Chris> compat package for the next release, and that's all you need to do?

  That would suffice, except for bug-fixes, security holes.

    Chris> What's the benefit of separate, parallel development of two C
    Chris> libraries at the same time?

  With reach-over Makefiles, I think that that the pain can be relatively
low. The biggest problem I see is in the #include files.a

    >> Why even have a major number?

    Chris> Good question.  Once you come to understand the implications of
    Chris> bumping the major number, it does seem fairly obvious to follow on and
    Chris> ask that.  I've not come up with any good reason other than "in case,
    Chris> because of some horrible catastrophic problem in the future, you
    Chris> Really Really Really need to bump them."

  It seems to me that the fundamental problem is that the libc major number
is closely associated with:
   1) the ABI	      
   2) as expressed with the files in /usr/include

  We have hacked around #2 via rename, which works for kernel ABI issues, but 
not for other pieces. 

  I want to emphasis that I am trying to be constructive. We need to have a
way that we can grow, that people like Jason and others can innovate in the
way that he is very good, while permitting people to generate binary packages 
that work across some reasonable selection of releases. 

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [