Re: obsoleting shlibs - what's the plan

Michael van Elst <mlelstvserpens.de> writes:

> On Wed, Mar 26, 2008 at 10:53:02AM -0400, Greg Troxel
wrote:
>
>> I updated using BUILD-NetBSD from etcmanage, and
then ran 'postinstall
>> fix obsolete'.  It deleted libraries that I think
it shouldn't have:
>
>> So, I think these shouldn't have been marked
obsolete, and that in
>> general that we should not obsolete previous major
shlibs, just minor
>> ones (e.g., if .so.3.1 arrives we can remove
.so.3.0, but not .so.2.1).
>
> I believe we should, these old and new libraries do not
coexist nicely.

I don't understand.  Which kind of problem arises?

  programs linked against the old major won't dynlink right

  programs linked against the old major won't do the right
thing

  new programs won't link right if the old major is present

  programs linked against the new major won't dynlink right

  programs linked against the new major won't run correctly


The only problem I can see is if the config file formats
changed so much
that the old libraries get confused by the new config file
formats.

If we do anything other than un-obsolete the older krb libs,
we need an
entry in UPDATING.

gdtir.bbn.com (Greg Troxel) writes:

>I don't understand.  Which kind of problem arises?

When you use the new kerberos, then it is possible that the
old libraries won't interoperate because of missing
features.

>If we do anything other than un-obsolete the older krb
libs, we need an
>entry in UPDATING.

True.
-- 
-- 
                                Michael van Elst
Internet: mlelstvserpens.de
                                "A potential Snark may
lurk in every tree."

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
dhollandnetbsd.org