Subject: Proposal: Support for pure runtime dependancies
To: None <tech-pkg@netbsd.org>
From: Ty Sarna <tsarna@sarna.org>
List: tech-pkg
Date: 12/19/2003 13:20:21
Problem: we have many cases of packages that currently DEPEND on other
packages because they are needed at runtime, yet DEPEND has an implied
BUILD_DEPENDS and other semantics that is not always warranted.

For example:

If foopaint depends on png, it is reasonable that deleting png and
installing a newer version will require foopaint to be rebuilt, because
foopaint is actually linked with png, and the ABI may have changed.

If foopaint depends on netpbm, it is not very reasonable that upgrading
netpbm will require foopaint to be rebuilt. It's exceeding unlikely that
a newer netpbm will break foopaint, because foopaint will not build
differently depending on what netpbm is installed. Yet at the moment,
the user must do a lot of unnecessary work to update everything that
depends on netpbm, because we cannot distinguish between a pure runtime
dependancy and a buildtime-and-runtime dependancy. This is especially
painful with pacakages that have a *lot* of other packages depending on
them. Apparently xscreensaver-gnome is another example -- 30 packages
depend on it. But do you really think any of them need to be rebuilt to
update xscreensaver-gnome?

Right now you can do "pkg_delete -F" and reinstall, but this has major
problems: the dependancy is lost, so now the user may forget and
pkg_delete it again later, assuming since it succeeds without -F that
all is fine, not realizing things have been broken. And, the user must
guess which things are safe to do that with because they are a pure
runtime dependancy, and which have buildtime dependancies.

Proporal: revive RUN_DEPENDS with new semantics (I don't even recall
that we had a RUN_DEPENDS or what it did, but Al says so...)

Semantics:

Let's say foopaint has RUN_DEPENDS on netpbm

1) If building foopaint and netpbm is not installed, build netpbm, as we
would now for DEPENDS. However, register the dependancy differently
when we install foopaint, so that the package tools can act differently
with RUN_DEPENDS.

2) pkg_delete netpbm is allowed without -F, but warns that netpbm will
need to be reinstalled before (list of packages RUN_DEPENDing on netpbm)
are used. The dependancy "foopaint RUN_DEPENDS netpbm" is retained (even
with -F)

3) There is a tool, or feature of pkg_info, or whatever, that will tell
you about unsatisfied runtime dependancies. Perhaps it is even called
from the nightly cron? Perhaps pkg_info's default display flags packages
with unsatified runtime dependancies also?

4) IWBNI there is a way to ack for all unsatisfied runtime dependancies
to be built and installed.

5) IWBNI installing netpbm will tell you things like:

All of package foopaint's runtime dependancies are now satified.
Satisfied one runtime dependancy of bazimagetools, still needs:
	picsmasher>=1.10
	gifmunger>=42.7


Comments?