Re: obsoleting shlibs - what's the plan

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Mar 27, 2008 at 10:19:59AM +0100, Havard Eidnes wrote:
 > > Running the app will now load both kerberos libraries. This probably
 > > won't work [...]
 > 
 > Yep, this will in all probability be a problem.
 > 
 > However, as has been pointed out, with proper version number
 > hygiene for the shared libraries, at least the worst effects of
 > this can probably be avoided.  What should happen when you bump
 > the major of libkrb5 is that any other library which uses libkrb5
 > *also* needs to have it's major number bumped, and it needs to be
 > recompiled and installed, of course together with any headers
 > which define the new interface.  Yes, this is true both for
 > shared libraries in the base operating system, as well as any
 > third-party libraries, be they out of pkgsrc or from somewhere
 > else!

Right, I mentioned that (though not in quite the same terms) and it
doesn't scale very well. Also, realistically, we cannot expect that
random things users may have put in /usr/local/lib will be handled
correctly - the requirement to compile a new version before linking
any new executables has to be enforceable.

 > This is why I raised the hand in warning what we need to prepare
 > for if we are going to bump the major of libc as a consequence of
 > changing the size of time_t to be 64 bits, because which shared
 > library *doesn't* use libc?  Doing the version handling dance
 > properly to preserve backwards binary compatibility as good as
 > possible (given what we have to work with) and at the same time
 > avoiding the version clash described above requires a *lot* of
 > effort and coordination!

Right.

(It doesn't help that there are now like four or five simultaneous
threads about this stuff going on at once...)

-- 
David A. Holland
dholland%netbsd.org@localhost