Subject: Re: CVS commit: pkgsrc/mk/buildlink3
To: Robert Elz <kre@munnari.OZ.AU>
From: Johnny C. Lam <jlam@NetBSD.org>
Date: 01/25/2004 19:11:26
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
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.
> 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
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.
-- Johnny Lam <jlam@NetBSD.org>