On Mon, Oct 11, 2004 at 12:09:02AM +0200, Pavel Cahyna wrote:
> > > > 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.)

If I'm not misrepresenting you, you're taking the view that package
views is too heavyweight for shared libs, therefore you think it's too
heavyweight in general.  I disagree with the first part of that, and
think that they are a general solution to a problem that exists and is
with us right now.  The fact that this thread is called "make update
hell" should tell us that maybe other people see this as a general
problem, too.

Package views were conceived not just for shared libraries, but for
whole software suites, so that multiple versions of conflicting
packages can be installed at any one time, and things will work
properly.  So that you can try out new versions of existing packages
without compromising existing installations.  Or you can try
development versions on the same machine as they will be running once
in production, so that configuration files need minimal, if any,
modification.

There may be some opposition amongst the user base to upgrading to
a newer version - some functionality may have been removed, or the
curmudgeons amongst us may prefer the bloatless older version.

None of this is a problem for package views, which provides a very
powerful vehicle for a number of things.

Having said all that about the holistic view, I also believe that
package views work perfectly with shared libraries - in fact, that's
one area in which I believe they excel.

Regards,
Alistair