Subject: Re: fix for databases/rrdtool
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 02/28/2000 19:54:26
On Mon, 28 Feb 2000, Greg A. Woods wrote:
> 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
_Your_ position is clear. My position, is that's it's horribly
inelegant to rebuild and reinstall the same library several times.
Plus, it's a waste of time and disk space. Evidently, some of the
other pkgsrc maintainers also believe it's worth the trouble to
consolidate libraries, as much effort goes into coordinating updates
to shared libraries, whereas otherwise we would not bother.
Moreover, as long as the volunteer/maintainers are willing to fix
problems as they arise, they should have the license to do anything
they like. If you do encounter a problem due to an update/bug-fix to a
shared library, you're encouraged to file a PR, of course.
> 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
A recent update to gtk+ basically broke devel/maketool. I told the
author, Greg Banks, and he came up with a work around. How hard is
that (for me)? Distributing gtk+ static with every package that uses
it is not an option; no one does that.
> 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.
You said that already... and I've already told you I disagree...
> 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....
I'm not ignoring anthing. If you would please point out a concrete
problem with a package I maintain, I will try to fix it. I grow tired
of debating. Cheers.