[ On Monday, February 28, 2000 at 19:54:26 (-0600), Frederick Bruckman wrote: ]
> Subject: Re: fix for databases/rrdtool
>
> _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.

Pkgsrc should be about making it easy to install and use third-party
packages on the system (and indeed I think that's its official goal).

Pkgsrc definitely is not about having a most elegant and refined build
system for third party software -- that's quite obvious on first glance
and I don't see how it could possibly be so by definition of what it
tries to do.

In fact the goals of pkgsrc must be often fundamentally opposed in
certain ways to those goals of a package author, especially if binary
packages and interdependencies amongst binary packages are to be
properly handled (as they are just becoming to be in NetBSD's pkgsrc).
I.e. pkgsrc build modules must take care to deceive or replace the
package's build system itself where necessary, and to provide for it
where possible, such that external dependencies that'll be necessary to
support at run-time are all carefully recorded for that purpose.

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

The NetBSD organisation is full of, and surrounded by, pedantics, myself
among them I'm sure -- but this doesn't necessarily mean they're all
always on the right track and/or headed in the same general direction! ;-)
That's part of what makes NetBSD good, and part of what makes it so
frustrtating at times too!

From my own perspective, based on concrete experience in the matter, I
can be reasonably certain that many of the folks so eager to ensure that
everything sharable is shared by dynamic linking and only by dynamic
linking have never tried to maintain a production system with the binary
results of their creations.

Indeed given the tendancy to blindly make every library into a
dynamically loaded shared library forces pkgsrc maintainers to put much
effort into co-ordinating updates!  This seems to be more of a case of
the tail wagging the dog here....

With all this extra effort being put in up-front, and causing all that
extra effort for users of binary packages too, don't you think that at
least it's worth re-evaluating the pedantic drive to forcing dynamic
loading of all shared objects?  If you don't are you sure you're not
just avoiding the issue because you don't have to personally deal with
it?

While *BSD shared libraries are not quite so evil as M$ DLLs, they
aren't exactly the ultimate solution to optimising memory and disk space
and reusing code either.  After all one has to wonder why ld.so isn't
built into the kernel and why all binaries aren't dynamically linked....
While they may have their place it's apparent that they are not globally
applicable.

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

Another change-request PR to be "ignored" like so many in the DB?

Yes, I know that sarcasm won't help sway anyone's opinion on a matter
such as this, but it amuses me anyway....  :-)

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

Integrated third-party libraries are just a bigger warning sign for
anyone interested in making any changes to them -- the same basic issues
of software hygiene in configuration management apply even when
upgrading a library not directly integrated into any given package.  If
the package author says "requires gtk+ version 91.42" you've got to
wonder why he didn't also say "or newer" and you've got to be extremely
careful when you adapt his package to use a newer version of gtk+.

> > 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 don't recall you disagreeing specifically with that aspect, nor do I
recall your reasons if you did.  In fact I can't even begin to imagine
how you could find a valid argument against where actual experience
shows it to be true without first showing that my experience is
irrelevant despite it being .

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

Since you didn't seem to address these issues directly I got the
distinct impression that you were at least leaving them open...

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

Ah, um, this thread was started based on a package you don't seem to
maintain at the moment, so I guess it's up to you whether or not you
continue to join in the discussion or not.

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