On Sat, 26 Feb 2000, Greg A. Woods wrote:

# [ On Saturday, February 26, 2000 at 12:02:59 (-0600), Frederick Bruckman wrote: ]
# > Subject: Re: fix for databases/rrdtool
# >
# > If I understand the issue, that method rules out use of the depended
# > on library as a _shared_ library. Shared libraries are good,
# > especially those that are truly shareable (with unrelated programs),
# 
# Well, sometimes shared libraries are "good".  Other times they are a
# royal pain in the butt, especially when they are "pkg" libraries and
# you're trying to maintain some semblance of modernity in a production
# system using binary "pkg"s.  This wouldn't be an issue if the pkg system
# allowed multiple versions of sub-components to be installed
# simultaneously, but it doesn't (/opt here we come! ;-).

/opt has nothing to do with this.  You're thinking about the System V
pkg* tools which _can_ maintain multiple instances of a package (if
their config file allows it -- and not many do.)

If /opt shows up, to be frank, I'll be among those blowing serious chunks.

# In any case these are really side-issues to the central one that doing
# this kind of code maintenance in the pkg system is (or at least should
# be, if it's done right) a *LOT* more work than I think anyone really
# should want to do unless there are extenuating circumstances and
# desparate needs.

Agreed.  "In an ideal world", one would have binaries and libraries
consistently updated and _in sync_.

# The savings claimed by shared library advocates are sometimes far
# over-hyped.
# 
# A few bytes of memory and disk space, even over the lifetime of a
# system, is possibly miniscule in comparison to the maintenance
# headaches and overheads.  "Premature optimisation...." and all that.  :-)

The only thing I worry about in shared libs is installing one that doesn't
work and watching one of the shells (i.e. the one I log in with), or watching
the X system or something else go t!ts up.

# There are also non-trivial (i.e. measurable) processing costs to using
# shared libraries (just as there are sometimes non-trivial processing and
# I/O costs to starting a non-shared process for the first time).  If I
# remember correctly it wasn't even that long ago that someone did some
# actual timings of system builds on NetBSD to show the differences.

I would think that shared libs would help processing overall because the
relevant pieces of oft-used code would be always in the cache.  That doesn't
happen with static binaries (or does it?  Is the caching code smart enough
to sum chunks of code and check against what's in core?).

# 
# > Arena isn't being maintained at all (I've gotten no response to
# > emails), but whether the maintainers of an actively maintained package
# > would accept patches/requests to that effect are another matter. All
# > you can do is ask. <shrug>

If, Frederick, it's not being maintained, and you seem to be professing
such a like toward this particular piece of software, are you planning
to take over maintenance?  It might be the best shot you will see of
having a reasonably up-to-date copy.

				--*greywolf;
--
NetBSD: Resistance is futile!  You will be supported.