Re: obsoleting shlibs - what's the plan

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>>> (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

Seems to me that any of these, if true, are critical bugs in our shlib
implementation - isn't that kind of disambiguation exactly what major
version numbers exist for?

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B