On Mon, 4 Sep 2000 abs@purplei.com wrote:

> 	Currently updating a package involves deletion and
> 	re-compilation/installation of all the packages that depended on
> 	it. For many packages this is quite correct (anything depending
> 	on another package to link against its includes), but for
> 	others it is completely unnecessary (packages depending on
> 	other packages containing only executables and manpages).

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.

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.



Frederick