On Tue, Oct 05, 2004 at 10:08:53PM +0200, Pavel Cahyna wrote:
> > I found this one out the hard way. The problem occurs when the update results 
> > in a shared library being installed with a different revision number. 
> > Dependent code still references the library with the old number, yet, with 
> > the "make replace" you delete the old and install the new.
> 
> This sounds like a major deficiency of pkgsrc. A library package should never

I hadn't thought of that problem.  In retrospect, that seems odd to have
missed it.  (^&

Perhaps it never should happen.  "make update" avoids this, but
does it in an expensive way.


Maybe "make replace" could (or should) check compatibility.  However, that
presumes that the library versioning is done correctly.

Also, I tend to view "make replace" as an "experts only" way to tweak
libraries so that a big "make update" doesn't kill half your system.
You first "make replace" key libraries, then updating a major package
does not force that target to be also updated.  If "make update"
never allowed an incompatible library to be installed, then it
would sometimes fail.


> be upgraded to an incompatible version. AFAIK Debian solves this by having
> library packages with revision number embedded in their name (like libpng3
> or libc6). That way, packages depend exactly on the version they need, and
> multiple incompatible versions of a library can be installed in parallel.

My limited understanding is that pkgviews may help with this.  I have
not actually set up pkgviews.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/