I'm sympathetic to this notion, and a have a few observations:

1) There are two axes: one is how the program is used.  In addition to
   normal dynamic linking, there is static linking (which arguably
   shouldn't cause RUN_DEPENDS at all).  You mentioned netpbm as an
   example; this is the case of running other programs.  There is also
   dynamic loading at runtime (either a plugin sort of thing, or how
   guile modules such as guile-gtk load the underlying libs).

   With all of these cases (except static linking), there is an
   interface definition (even if not really defined properly), and it
   can change.   I agree that command-line interfaces are less likely
   to change, especially for very mature programs.

   But, the key issue is whether the author understands how others
   depend on it and how careful they are to avoid "bumping the major
   number", a concept that makes sense for command-line interfaces
   too.

2) The underlying problem common to all this is really the notion
   that "make replace/pkg_add -u" is dangerous.  This is often true -
   I have replaced libs that bumped major numbers of libraries and
   broken things.  With a way to record the dependencies on not just a
   package but the library versions (perhaps all in a pkg if any are
   used), and coupling that into declaring "make replace/pkg_add -u"
   reasonably safe if the shlib major version requirements are still
   met, I'd feel a lot more comfortable doing make replace.  (Really,
   I just do it and rebuild something if it loses.  I just did about
   20-30 packages this way, and the only breakeage was gabber because
   gnome-- had a shlib version bump.)

   We could do the same for program-running dependencies, with the
   pkgsrc maintainer assigning a "invocation API major version
   number", and bumping that if the calling conventions change
   incompatibly.

   Such convention changes could be detected by e.g. autoconf, so I
   don't agree that in the general case programs can be safely
   replaced.  I do agree that in practice it is safe enough that I'm
   willing to do it and live with the consequences, because it is
   almost always safer than the risks of trouble due to a failed build
   with make update.

-- 
        Greg Troxel <gdt@ir.bbn.com>