[ On Monday, February 28, 2000 at 16:29:10 (-0600), Frederick Bruckman wrote: ]
> Subject: Re: fix for databases/rrdtool
>
> On Mon, 28 Feb 2000, Greg A. Woods wrote:
> >
> > [ On Monday, February 28, 2000 at 10:21:56 (-0800), Berndt Josef Wulf wrote: ]
> > > Subject: Re: fix for databases/rrdtool
> > >
> > > Let me know about the final outcome on this discussion. I will not be
> > > interested in supporting rrdtool in future if it means to revert
> > > back to the libraries supplied with the package.
> > 
> > That would indicate that you find some clear and direct benefit from
> > upgrading them -- something perhaps that those of us actually using
> > RRDtool as distributed either don't know about or are not so worried
> > about.  Can you elaborate please on what those reasons might be?
> 
> That's not fair. The package maintainers are trying to put together a
> coherent system from disparate sources. I understand why developers
> might eschew shared libraries, but their problem is not our problem.
> If anyone would rather use the distributed RRDtool, he's free to do so.

I'm confused now.

I'm trying to find out why someone might really want to go to the
trouble to upgrade the libraries in RRDtool in particular.  Perhaps I'm
not aware of some problem that I'll eventually trip over.

As I think I said at the very beginning -- if there's a good reason to
replace a library in some package then it should be done, just so long
as it's done with care and planning.

I haven't encountered any problems with the libraries distributed with
RRDtool in particular so I'm quite curious as to what I might have
missed.

As for the issue of libraries in particular, you're seemingly ignoring
the fact that whether they are shared or not anyone attempting to use a
different release of a given sub-component from the one that's explictly
distributed with a package really has to do more than just a cursory
re-link and re-test before they'll know if they've made things better or
worse.  That's not to say that one shouldn't be equally careful when
using a different release of a sub-component that's not distributed with
a package, of course....

With respect to shared libraries in particular I am very wary of
unnecessarily introducing interdependencies between packages that might
share other packaged shared libraries.  The advantages of shared
libraries are completely and totally lost when you go and try to
implement incremental fixes to a production environment.  This goes
double for sites using binary-only packages.

I realise that without resorting solely to static linking there's no
adequate solution to these issues in pkgsrc today, but that doesn't mean
one should just bury one's head in the sand and ignore them....

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