Date:        Sun, 25 Jan 2004 16:46:21 +0000 (UTC)
    From:        "Johnny C. Lam" <jlam@NetBSD.org>
    Message-ID:  <20040125164621.3C8392DA1D@cvs.netbsd.org>

  | The new standard for modifying BUILDLINK_DEPENDS.<pkg> is to append to the
  | value instead of overriding.  The reason is so that the most restrictive
  | <pkg> dependency will always be a part of the dependency list.

I don't understand this.   How can a package possibly have more than
one version of some other package that it depends upon?   That is, if
A depends upon B, it might need B version x.y, or better, or between
x.y and x.z or something (or just possibly might not care at all), but
it cannot rationally require 2 different versions.

If somehow this has to do with dependencies of dependencies, then I
believe it is all on the wrong track - if A depends upon B, and both
A and B depend upon C, then B needs to be installed first, which will
mean that a suitable version of C for B will also be installed.   When
A comes to be installed, the version of C currently installed (which is
good enough for B) is either good enough for A, or it is not.  If it is,
then all is fine.   If not, C needs to be upgraded (which probably means
removing B to allow that to happen, the way things currently work).
When that's done, B will get re-installed, if the version of C now
installed is OK for B, everyone is happy - if not, then A and B are
simply incompatible, and cannot both be installed (because of requiring
different versions of C installed).

All this works just fine with one package only ever having one version
dependency on any sub-package.   What's more, it is all just the same
as now, as even if A did have both dependencies in its list, B (and
hence a C for it) is entirely possibly already installed.   In any
case, if a new C is needed (because it wasn't installed before, or
for any other reason), the only C that can be installed is the current
version, whatever that might be - which will either be good enough, or
not - either way, end of story.

The buildlinkN.mk files should have no dependency version in them at
all - how can a package possibly know which version of itself some other
package requires?   It cannot.   Sure, it might believe that a bug fixed
in version N is so important that everyone needs that fixed version,
but that's nonsense - the depending package may have known about the
bug already, and either know itself to be immune (doesn't use the
feature in question at all) or have implemented a work around (even to
the extent of failing to work if the bug in the dependent package gets
fixed).

Dependency information really all needs to exist where the version needed
is known - that's in the package that is using the dependent package.

Of course, for pkgsrc, that would mean vast amounts of work, racing around
to every package inserting the BUILDLINK_DEPENDS.x lines everywhere,
which is probably not justified as request to put upon anyone to make
happen - so we should leave those lines in the buildlink3.mk files for
now, but make them always be overridden by a setting in the depending
package (always) - then require all new packages to set the depends
explicitly (and as packages are revised, or otherwise touched, gradually
fix all the old ones as well).    Once it can be verified that all
includes of a buildlink3.mk file are accompanied by an explicit
BUILDLINK_DEPENDS setting, the one in the buildlink3.mk file itself
should be removed (and of course, no new buildlink3.mk files should
ever contain such a setting).

kre