[ On , February 18, 2000 at 14:32:43 (-0700), Chris Jones wrote: ]
> Subject: fix for databases/rrdtool
>
> Is there any reason I shouldn't commit this as patch-ah for rrdtool?
> It changes many occurrences of "/usr/pkg" to "${PREFIX}".

I really don't think it's necessary to make packages interdependent
unnecessarily.  I've been using rrdtool (1.0.13) happily and
successfully without using the latest/greatest versions of the libraries
it uses but rather simply using what came with rrdtool.

It gets to be a royal pain in the butt when too many low-level libraries
(such as gd) are shared amongst many packages.  (This is yet another
reason why shared libraries, especially when used outside of the OS
utilities themselves, are more trouble than they are worth in most
circumstances these days!)  That goes double when you're using binary
packages!  Obviously one should just stick with exactly what's shipped
with the release to avoid this pain, but unfortunately that would make
NetBSD's pkgsrc almost totally useless in the real world for production
systems!  :-)

On a more philosophical note I would also argue that one should not
arbitrarily replace components of an application, especially when the
application's author has gone to the trouble to directly integrate the
component parts into his distributed source tree.  It's one thing when
the author says something like "Before you install this pacakge you'll
need to install any version of blah, blarg-v2 or newer, foo-v1.3, and
bipity-v3 with the enclosed patch for it" and quite another when the
exact versions the application was developed and tested with are
supplied.  I didn't do any comparisons of the sources included with
rrdtool to see if they are virgin or not, but that's hardly the point --
a bug fix in a component can just as easily cause a new bug in the
application even if the compilation and link goes just fine.  Now I'm
not suggesting that rrdtool in this particular case wasn't well tested
with the new libraries....

Coming back to the real world for another generalisation I might also
point out that simply pkg-ising rrdtool with the stuff it comes with is
enormously easier than all the goop required to undo the author's
efforts.

Which reminds me -- I keep wanting to cook up a scheme where package
builds can in a sight-dependent manner partly ignore overly dependent
use of shared libraries from other packages (using system libraries is
OK, but libgd.so is right out in my books!)....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>