>Number:         10860
>Category:       pkg
>Synopsis:       Installed packages should not spuriously alter building of other packages
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 20 13:58:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Jim Bernard
>Release:        August 20, 2000
>Organization:
	Speaking for myself
>Environment:
System: NetBSD zoo 1.5E NetBSD 1.5E (ZOO-$Revision: 1.55 $) #0: Sat Aug 12 14:34:20 MDT 2000 jim@zoo:/home/tmp/compile/sys/arch/i386/compile/ZOO i386


>Description:
	This is essentially a generalization of PR 10755 (now closed).  What
	was observed there, and today by me, was a failure of freetype-lib
	to build on account of an existing installed package.  In the discussion
	of 10755, it was surmised that an older freetype-lib installation
	was interfering, but even after its deletion, the problem continued
	because of freetype-related header files in /usr/pkg/include.  In
	my case, those files were associated with the package freetyp-1.2
	(I had no freetype-lib package already installed), and that may have
	been the real problem in the case of 10755 as well.

	However, simply observing that some installed package is causing
	trouble and giving up on really fixing the true problem while
	leaving it to users to (re)discover and delete the offending
	installed package first amounts to sweeping the problem under the
	rug.  Here's why:

	  (1) The problem will recur with packages for which is has already
	      occurred: other people will run into it, and there's
	      no attempt to prevent it and no way to adequately warn them.
	      A comment or CONFLICTS (which only takes effect at _installation_
	      time, not _build_ time) in the Makefile would help, but wouldn't
	      solve the core problem.

	  (2) The problem will eventually recur with other packages, possibly
	      manifesting itself as some subtle misbehavior of a successfully
	      compiled program or library, or possibly as some dramatic
	      failure to compile (as happened with freetype-lib).  Those
	      subtle cases, of course, could be extremely difficult to find,
	      not the least because they depend on the exact pkg history of
	      the machine on which the build is done.

	  (3) The real problem is that package builds should not be
	      using installed pkg headers (-I/usr/pkg/include) unless it's
	      absolutely necessary because of a dependency (and even then,
	      there's a potential for things to go wrong unless proper
	      care is taken).  In the case of freetype-lib there are no
	      dependencies on other packages except libtool, so (I think)
	      there's no need to look in /usr/pkg/include at all.  (However,
	      the installation would presumably overwrite the old files,
	      so there needs to be a CONFLICTS assignment in the Makefile
	      for that reason.)  Other packages may be different.  In those
	      cases where a package really needs to find headers (and/or
	      libraries) in /usr/pkg, the local (build) tree should be
	      searched first (e.g., -I. -I/usr/pkg/include, rather than the
	      other way around), so as to remove the possibility of picking
	      up the wrong (old) file(s) during compilation.

	  (4) As it clear from (2) and (3), this problem has the potential
	      to affect (possibly many) other packages, if not now, then at
	      some time in the future, so a general fix is required.

	  (5) It should not be an error for a person to attempt to build
	      a package on a system with existing installed packages,
	      whether those include an earlier version of the package
	      being built or not.

>How-To-Repeat:
	E.g.: try to build freetype-lib-1.3.1 with freetype-1.2 already
	installed.

>Fix:
	I don't know, but I expect some changes to bsd.pkg.mk will be needed,
	since configure for freetype-lib prints messages like:

	  checking whether the C compiler (cc -O2 -I/usr/pkg/include -I/usr/pkg/include  -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib) works

	which probably contains contributions from one or more macros defined
	in bsd.pkg.mk.
>Release-Note:
>Audit-Trail:
>Unformatted: