[ On Thursday, June 7, 2001 at 17:19:59 (-0400), Johnny C. Lam wrote: ]
> Subject: The infamous hidden dependencies problem
>
> Hidden dependencies seem to occur primarily with packages that use GNU
> configure scripts, and they seem to mainly occur with pkgsrc-installed
> libraries being found due to the -L${LOCALBASE}/lib flag passed via
> LDFLAGS.

Yes!  This is the worst of the issue.

The "hidden dependencies" problems can easily occur with any package
that uses some form of auto/self-configuration, eg. GNU Autoconf or
Metaconfig generated configure scripts, and the like.

They could possibly also occur for any code that uses #if etc. to check
for various things that might be found in the compilation environment,
though mostly those kinds of checks are restricted to things that won't
create hidden dependencies, at least not so long as a binary package is
only ever loaded on a machine running the exact same O/S revision it was
built on.

The most absolute solution might be to not ever run any self-/auto-
configuration script when building the package but instead to always
supply pre-defined configurations.  The biggest problem I see with this
is that then pkgsrc might have to include one config for each supported
platform and release, which would soon become a nightmare because
package developers would have to maintain access to every supported
platform and release and maybe even test on all/many of them!

>  I'd like to propose the following solution, though it may
> involve some work.
> 
> Some of you may have noticed some commits related to buildlink.mk files.

Hmmm, not yet, but then I've not been reading the pkgsrc commits.

> The idea behind them is that they define targets that are meant to be
> called at pre-configure time that link libraries and headers for that
> package into ${BUILDLINK_LIBDIR} (${WRKDIR}/lib) and ${BUILDLINK_INCDIR}
> (${WRKDIR}/include).  The package that needs to use those headers and
> libraries then passes -I${BUILDLINK_INCDIR} to CFLAGS and/or CPPFLAGS and
> -L${BUILDLINK_LIBDIR} to LDFLAGS.  To prevent accidental linkage against
> libraries already installed under ${LOCALBASE}, we only pass the rpath
> flags to LDFLAGS, so instead of:
> 
> 	LDFLAGS+=	-Wl,-R${LOCALBASE}/lib -L${LOCALBASE}/lib
> 
> we have:
> 
> 	LDFLAGS+=	-Wl,-R${LOCALBASE}/lib
> 	LDFLAGS+=	-L${BUILDLINK_LIBDIR}
> 
> The thing that needs doing is for all the packages that install libraries
> and headers, create a buildlink.mk file, then for all the packages that
> use libraries and headers, change them to use buildlink.mk files.  For
> an example, see pkgsrc/print/cups.

I like this!  It is very much along the lines of what I've hacked into
my own pkgsrc/mk/bsd.pkg.mk, though my hacks are far more brutish, far
less reliable, and don't nicely handle extensibility in the way
buildlink.mk files would.  I also don't use separate symlinks or
directories -- just require that each package using some other's headers
or libraries explicitly include its own "-I${PREFIX}/include
-L${PREFIX}/lib".
 
I will try this with the new squid package I'm working on and see if it
helps!

This proposal would certainly reduce the number of local changes in my
pkgsrc!  ;-)

> The problem with this is that it doesn't protect against libraries
> installed in ${X11BASE}.  This isn't an issue if you use xpkgwedge, as all
> the package libraries are installed under ${LOCALBASE}, but if you do
> install libraries under ${X11BASE}, then if a package has USE_X11 defined,
> then any package libraries installed under ${X11BASE} may be accidentally
> found by the configure script.

I would most humbly suggest that this is not a problem that need be
dealt with.  :-)

People building binary packages (and those using them!) should learn to
use xpkgwedge!!!  ;-)

On the other hand it might better (though much more work) to move all
installed library and header files into "private" sub-directories.
I.e. never to mix them with "system" or other package headers and
libraries.  This would solve the X11BASE problem.

The drawback to this latter approach is that it makes installing other
third party software that might use a package header and/or library a
bit harder to do (i.e. you can't just use -I/usr/pkg/include, for
example, as an all-encompassing solution for everything any more).

-- 
							Greg A. Woods

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