> > > So your stance has moved to that of "it doesn't matter what minor version
> > > of the shared library is used, because it's compatible through the major
> > > version branded into the SONAME in the binary"?
> > 
> > Yes, exactly. (...)
> > 
> > Is this view incorrect?
> 
> Well, I don't always trust third-party code to bump major numbers at
> the correct time, and for the right reasons, but maybe that's just
> rampant paranoia on my part.  In addition, there may be bug fixes in
> later versions of a shared library with the same minor number.  Or new
> functionality, but not covered by an ABI change.  Or a security fix. 

For bug fixes and security fixes, there is already something like
RECOMMENDED in pkgsrc, no? 

> In general, relying on the major number to be the sole arbiter of
> whether or not a library is compatible, wanted and necessary will work
> for a lot of occasions, but I would doubt that it would work all the
> time for everyone.

OK. But, can there be any cases when it doesn't work AND it is not a bug
in the upstream software? Not increasing major number when ABI change or
minor number when a function is added count as a bug, IMHO. There is not
much that pkgsrc can do about upstream bugs. (Always recompiling
everything (make update) doesn't count, because you should always have the
option to recompile everything if such (hopefully infrequent) bugs in
upstream packages are encountered.)

>  
> > > > libraries it seems to be an overkill. I also think that concerns raised by
> > > > Greg A. Woods in
> > > > http://mail-index.netbsd.org/tech-pkg/2003/08/21/0049.html may be valid.
> > > 
> > > I am absolutely distraught that Greg's views are different from my own.
> > 
> > Sorry, I'm not sure that I understand, not being an English native
> > speaker.
> 
> Oh, it's just that I'd be more worried if Greg and I were to agree.

HAHA :-)

Bye	Pavel