G'day,

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.

cheerio Berndt


Greg A. Woods wrote
> [ On Sunday, February 27, 2000 at 00:46:01 (-0600), Frederick Bruckman wrote: ]
> > Subject: Re: fix for databases/rrdtool
> >
> > You suggested committing the complete set of changes to update an
> > included library to another version. Even assuming that such a set
> > were available, that's a lot more work, and pkgsrc baggage, than
> > simply changing the linker invocation in the packages Makefile.
> 
> The pkgsrc maintainer would of course have to generate the upgrade
> patch.  Yes it would be more work.
> 
> > Unless
> > I misunderstood you completely, your idea is absurd on the face of it.
> 
> The point of that option was to maintain the integration of the library
> just as the original author intended it....  It also happens to goe a
> lot further towards meeting the larger goal any maintainer should be
> striving for in a case such as this -- a more careful and considered
> upgrade of the component in question.
> 
> The conclusion though should be that nothing be done unless it is
> clearly necessary *and* safe to do.  Although pkgsrc makes it relatively
> easy to maintain localised changes to third party packages, I see a lot
> of unecessary patches and changes that in general make pkgsrc not only
> more cumbersome to use, but obviously more work to maintain too.  In my
> experience with pkgsrc, and in particular my experience with using and
> evolving binary packages on production systems, I've found that pkgsrc
> change sets should be restricted to those which are absolutely critical
> for portability and for fatal bug fixes.  In particular I'm rather
> unhappy about most of the changes that are introduced in order to make
> shared libraries more prevalent (except perhaps where the package is
> just a stand-alone library) and especially unhappy about the combination
> of such changes with changes that also upgrade or replace integrated
> components from packages.
> 
> It would seem on casual inspection that the FreeBSD ports system has
> gradually learned this lesson as it has accumulated an ever larger
> collection of packages, at least in a few places where I've looked.  I'm
> hoping the same kinds of changes will come about in the NetBSD pkgsrc
> collection too.
> 
> I don't know if there's any stated goal to make NetBSD's pkgsrc work
> well as a way of keeping binary packages up-to-date or not, but I must
> say that in practice there is an extremely powerful desire to do this
> for anyone using NetBSD in production environments, especially given the
> relatively low frequency of NetBSD releases.
> 
> -- 
> 							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>
> 


-- 
Name    : Berndt Josef Wulf            | +++ With BSD on Packet Radio +++
E-Mail  : wulf@ping.net.au             |    tfkiss, tnt, dpbox, wampes
ICQ     : 18196098                     |  VK5ABN, Nairne, South Australia 
URL     : http://www.ping.net.au/~wulf | MBOX : vk5abn@vk5abn.#lmr.#sa.au.oc
Sysinfo : DEC AXPpci33+, NetBSD-1.4    | BBS  : vk5abn.#lmr.#sa.aus.oc