[ On Friday, February 8, 2002 at 10:33:23 (+0100), Thomas Klausner wrote: ]
> Subject: Re: Handling 3rd party rc scripts
>
> While people knowing exactly what they're doing might get away with
> doing this, I don't recommend taking up this practice.

I have no issues with recommending it to anyone -- even non-programmers,
so long as they don't try to follow pkgsrc-current.  Indeed the result,
with only standard system pathnames to deal with (i.e. only well known
places to look for things), is much easier for end users to understand
and manage -- they just want to use the syste, and they don't really
care where its component software came from or how it got there.  Every
such end user who has used my systems has complimented me on the
simplicity, elegance, and clean layout.

>  The problem is
> that you might get additional unwanted (and unnoted) dependencies if a
> configure script just goes and looks for whatever libraries it might
> work with, some of which might not be DEPENDencies in the package; if
> you then deinstall the configure-found package, any packages that
> depend on it get broken...

So far this actually has not been a problem for me -- however I only
deal with a relatively tiny percentage of all packages on a regular
basis.  :-)

Note that before building a package with LOCALBASE=/usr I first build it
and test it on a development system with LOCALBASE=/usr/pkg.

When I next build it with LOCALBASE=/usr I then compare the resulting
configuration and functionality to make sure nothing "extra" was found
that might result in an un-declared run-time dependency.  Where possible
I also check for, and register, build dependencies.  I.e. I am very
diligent about adjusting the DEPENDS settings to include all of the
possible features that may have run-time depenedencies, or where
possible the configure parameters to ensure that it only finds what I
tell it to find.

I also only build and use binary packages for production systems, and
where possible I test them on a virgin machine.

I am _very_ leary of hidden dependencies in packages.  I've been doing
this since 1.3.3, and long before buildlink came along, as I had learned
very quickly that binary package runtime dependencies were very fragile
and often wrong and that they had to be rigorously tested every time.

(I'm also slowly working towards modifying pkgsrc so that I can get rid
of all shared-library-based dependencies by using only static libraries.
The joy and relief the result has already brought me is very
encouraging.  I no longer have to de-install huge tracts of unrelated
packages when some core library, such as libjpeg or libpng, or worse
libgd, is upgraded!)


As for LOCALBASE=/usr causing problems for other people who might not be
so careful to test their results, this normally isn't as much of a
problem as you might think.  For one it'll only really affect folks who
try to follow pkgsrc-current and those people should be experienced
enough to diagnose such problems.  Most people won't be de-installing
arbitrary packages either -- they'll just add to a growing suite.


> In other words, buildlink.mk won't work in the intended way for you.

Well, since I first test with LOCALBASE=/usr/pkg, it does in fact work!  ;-)

In reality buildlink has only made my life a lot easier -- it hasn't
really changed any of my final results.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>