Re: obsoleting shlibs - what's the plan

[Greg Troxel <gdt%ir.bbn.com@localhost>]

mlelstv%serpens.de@localhost (Michael van Elst) writes:

This is now moot, as Luke said he fixed the set lists to remove the
obsolete tag on the old libs.

> I believe that programs linked against the old libraries
> will not work or not work correctly when they start using
> these libraries, i.e. when they call kerberos functions.

Can you explain why?  Please assume that they worked correctly before
the upgrade.

> So, the only use of the old libraries will be for ballast
> to keep the linker happy.

That only follows from your unproven assertion above.

> We have two possible scenarios:
>
> - old libraries are dropped and programs linked against them will
>   fail, telling everyone that the corresponding package probably
>   needs a rebuild anyway.

This is hostile to users and not the standard NetBSD practice.

> - old libraries are kept, some programs may work without fault,
>   some may fail in subtile ways. The only way to get known behaviour
>   is to rebuild the corresponding packages, but now you have to
>   find the affected programs yourself.

If anything, this is a general problem of updating shlibs.  Your
assertion of failure seems unfounded.  It would be nice to have some
utility to mark packages unsafe_depends if they link against a base
system lib for which a higher major is available, and then
pkg_rolling-replace could straigthen all that out.  But that step can be
done separately.

> How many packages are using Kerberos without specifying an option
> (which tells me that the user requires Kerberos functionality)
> and will be affected?

Quite a few I think; it's pretty normal for pkgsrc programs

> All this only happens, when you do an upgrade to the base system.
> In my experience I have to rebuild many packages (i.e _all_ due to
> very limited update handling in pkgsrc) after I upgrade the base
> system to another release. Now you have to do it also when you upgrade

My experience has been that it has basically not been necessary to
rebuild packages, with very limited exceptions.

> a -current system after a large subsystem was changed. I don't consider
> this a problem or even worth this discussion.

Many others consider it a problem; the NetBSD way is to be careful about
binary compatibility.  It's not just about current; had this remained
then it would also have happened from 4 to 5.