Subject: Re: fix for databases/rrdtool
To: NetBSD Packages Technical Discussion List <>
From: Greg A. Woods <>
List: tech-pkg
Date: 02/27/2000 14:23:59
[ 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      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>