On Mon, Jan 26, 2004 at 01:43:27AM +0700, Robert Elz wrote:
>     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.

It doesn't require two separate versions.  If a package's DEPENDS
contains:

	zlib>=1.1.4nb1:../../devel/zlib
	zlib>=1.2.1:../../devel/zlib

then it simply states that any zlib that is used as a dependency for
the package must satisfy _both_ of the restrictions listed in DEPENDS.
This is merely some bookkeeping issue to make sure that we never
downgrade a dependency by explicitly setting a BUILDLINK_DEPENDS.<pkg>
line in some buildlink3.mk file somewhere.

[snip]
> 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).

No, we do not increase them whenever the package is updated.  The
dependency version in the buildlink*.mk files are only changed whenever
one of the following two criteria are satisfied:

    (1) a security fix is added to a library, or
    (2) the major number of a shared library has increased.

The dependency versions are again bookkeeping issues, this time to ensure
that binary packages with wildcard dependencies will work correctly.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>