Subject: Re: fix for databases/rrdtool
To: NetBSD Packages Technical Discussion List <email@example.com>
From: Berndt Josef Wulf <firstname.lastname@example.org>
Date: 02/28/2000 10:21:56
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.
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 <email@example.com> <robohack!woods>
> Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>
Name : Berndt Josef Wulf | +++ With BSD on Packet Radio +++
E-Mail : firstname.lastname@example.org | 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