There had been discussion in the past about having some dependencies based
on actual filename. This would be useful for depending on a library with
actual major (and minor) version.

This would be useful for when packages have an open-ended requirement like
png>=1.2.4 which would also mean some future version like 3.12.5 would
work. Another example may be unrelated to a shared library, but some
version of an interpreter, like tcl>=8.3.2, which could mean
tclsh12.25.

pkgsrc can already automatically generate lists of what libraries are
provided using the CHECK_SHLIBS functionality (and recorded as PROVIDES in
the +BUILD_INFO files.) (Although, maybe they shouldn't have full path
recorded.)

FreeBSD has dependencies based on actual filenames. For example:

 LIB_DEPENDS=    expat.4:${PORTSDIR}/textproc/expat2

 BUILD_DEPENDS=  ${SITE_PERL}/Error.pm:${PORTSDIR}/lang/p5-Error

 RUN_DEPENDS=    bash:${PORTSDIR}/shells/bash2

I don't think all methods are needed. BUILD_DEPENDS based on a file is
probably never needed. I think just FILE_DEPENDS is fine.

For pkgsrc, I would make these like the following (using my examples from
above):

  FILE_DEPENDS+=	lib/libpng.so.3:png>=1.2.1:../../graphics/png

  FILE_DEPENDS+=	bin/tclsh8*:tcl>=8.3.2:../../lang/tcl

Notice I used wildcard.

(It is hard to know what is compatible in the future, so even if tclsh9*
is fine, the package depending on tclsh8* will have to be reinstalled.
Those familiar can improve this.)

And pkgsrc would check both requirements.

Or maybe our regular DEPENDS can allow three entries (and if three, then
first is filename required).

From comments in ports/Mk/bsd.port.mk:

  LIB_DEPENDS - A list of "lib:dir[:target]" tuples of other ports this
  package depends on.  "lib" is the name of a shared library.  make will
  use "ldconfig -r" to search for the library.  lib can contain extended
  regular expressions.

Under FreeBSD (and NetBSD) ldconfig -r lists the current contents of the
hints file (without modification). Under Linux boxes, you'd use -p (or
--print-cache).

I don't think that using ldconfig is the correct way to do this. Simply
checking for file would be better and easier.

The FreeBSD method doesn't not include the filename that it depends on in
its +CONTENTS file. I think our method should.

RPMs also appears to do dependencies based on filenames (really sonames).
RPM runs ldd on every executable and provides a list of shared libraries
that it requires. RPMs that provide shared libraries add the library's
soname to a capabilities list. Then the automatic dependency processing
attempts to do the right thing.

Debian packages do not have dependencies based on filenames.

Our +REQUIRED_BY file can be extended to also include the filename
required (if was indicated in actual build Makefile).

As some of you may know, I have used my custom pkg_add with an upgrade
option. (It doesn't not delete -- but overwrites, removes old files, puts
back +REQUIRED_BY file, and runs a INSTALL "UPGRADE" target).

I could extend this so when a upgrade is to happen it can check the
+REQUIRED_BY file and then verify that the new package to upgrade to has
that file matched in the +CONTENTS file. If it does, then that would save
a lot of time and hassle when upgrading packages providing libraries. (And
if it doesn't match, then of course, it would fail and the admin would
reinstall all those packages -- which is okay and the right thing to do
and what is already done now.)

I guess the other alternative is to get rid of the open DEPENDS by
defining a set range, but that could be hard to know since versions of a
package name don't always correlate to versions of individual components.

Or the DEPENDS could be defined as one specific version, but that doesn't
improve any simple upgrade method at all.

And feedback would be appreciated ...

   Jeremy C. Reed
   http://bsd.reedmedia.net/