On Mon, 4 Sep 2000, Frederick Bruckman wrote:

> I've thought about that. We have two problems. We're building and
> installing packages in the DEPENDS list that aren't really necessary
> for building and installing the package at all. Another is that the
> package no longer contains the information of exactly which packages
> it was built against. Even if you track down the RCS ID's in the
> +BUILD_INFO file, you can not know what was installed on the build
> system.
> 
> I propose to revive RUN_DEPENDS, and to change the semantics of
> BUILD_DEPENDS. (All after the freeze!) BUILD_DEPENDS will specify
> packages that are required to build, and RUN_DEPENDS will specify
> packages that are only required to run. Plain "DEPENDS", specified in
> the package "Makefile", implies both. Now the binary package will have
> a +BUILD_DEPENDS file with the union of all the BUILD_DEPENDS and
> DEPENDS with __wildcards__ __fully__ __resolved__, and a +RUN_DEPENDS
> file with all the unresolved wildcards from DEPENDS and RUN_DEPENDS.
> 
	Seems very reasonable.

> For most of bsd.pkg.mk, DEPENDS -> BUILD_DEPENDS, so that you don't
> ever need to install the RUN_DEPENDS to build a package. For the
> transition, the "@pkgdep" entries are constructed from the RUN_DEPENDS.
> The +BUILD_DEPENDS is stored in the package simply for reference.
> 
> Short term, this solves the problem you stated.
> 
> Long term, I have an idea for a solution to PR 10835. Perhaps it would
> be feasible to do away with the +REQUIRED_BY altogether, and instead
> construct a database of all the "DEPENDS" (RUN_DEPENDS) for all
> installed packages? I'm thinking of an "inverted" index, sorted by
> wildcard, with two additional items: a resolution of the wildcard or
> an "unknown" token, and a list of all packages that have listed that
> wildcard in @pkgdep (=DEPENDS). Like so
> 
> xpm-*		xpm-3.4k	wmx-5.0,knews-1.01b1,xpdf-0.91
> png>=1.06	png-1.08	knews-1.01b1
> png-*		png-1.08	foo-1.01
> ...
> 
> Such a database would evidently be very easy to construct on initial
> installation of a package. To build a new binary package, you first do
> a "pkg_delete -r". This searches the second column, and deletes all
> the packages in the third field for entries that match. It may also be
> necessary to search for, or clean up, matches in the third field for
> the package in question. (That's when that package depends on some
> other.) To delete the package __without__ deleting all the
> dependencies (perhaps you already have a binary package), you do
> "pkg_delete".  This simply finds the matches in the second field, and
> sets them to the "unknown" token. Presumably, it'll be possible to use
> this token to list the unsatisfied dependencies.

	This seems to cover pretty much everything - presumably you'd
	want some form of pkg_admin command to rebuild the pkgdepends
	database in the event of problems.

                David/absolute
			       -- www.netbsd.org: A pmap for every occasion --