[ 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! ;-).

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.

> because they reduce the size of the binaries, and reduce the memory
> requirements on an active system (where all those unrelated programs
> are running).

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.  :-)

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.

> That's why I patched wwww/arena to use shared libpng,
> libjpeg and libz; in fact, to not even extract its included versions.
> Compared to Greg's idea, of pulling up all the changes in the included
> package, patching the make system is trivial.

Either way if you don't understand the application code deeply enough to
know if something might break when a new library is used, and/or if you
don't test extensively enough to ensure that nothing does break, then
you really shouldn't do such upgrades.  Yes sometimes these kinds of
"upgrades" are easy and might afford all kinds of benefits.  However it
is very important not to forget that they can be dangerous and that one
must do an extra amount of testing and sometimes even code reading to
ensure hidden problems don't suddenly surface when least expected.

I would recommend not ever upgrading a package's integrated library
unless there's a clear and common benefit to using the new library.
 
> 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>

Taking on the maintenance of an application is an entirely different job
than simply writting a 'pkg' module for it and perhaps including the odd
localised bug-fix in that module.

-- 
							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>