Subject: Re: CVS commit: pkgsrc/mk/buildlink3
To: Robert Elz <kre@munnari.OZ.AU>
From: Quentin Garnier <email@example.com>
Date: 01/25/2004 23:28:34
Le Mon, 26 Jan 2004 04:11:30 +0700
Robert Elz a ecrit :
> Date: Sun, 25 Jan 2004 19:11:26 +0000
> From: "Johnny C. Lam" <firstname.lastname@example.org>
> Message-ID: <20040125191126.GA8806@NetBSD.org>
> | 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
> But why would a package's depends say that? Surely that would be a
> bug, it needs only the 2nd of those two, doesn't it?
Well, the 2nd is the one to consider. And the change you're commenting
was precisely made in order to be sure such a dependency is preserved
through the buildlink inclusion process.
> | 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.
> But I don't think there should be such a setting, anywhere.
> | 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.
> But why should my package care about either of those? I don't care
> what major library version it is, that's irrelevant to me. I only care
> about security fixes if they apply to some function that I'm using,
> otherwise they're irrelevant. You cannot possibly know either.
Sure, we could require people to rebuild all installed packages that don't
match the version in pkgsrc, but trust me on that, we would get a lot of
We need a pkgsrc package to expose a minimum requirement in its buildlink2
file to say one of two things (and that's exactly what Johnny was saying):
o Packages linked against earlier versions are unsafe or cannot be
o Packages using that version of the buildlink file might not link with
the installed version
Of course, in an ideal world, each package should describe in the Makefile
all of its requirements. Frankly, that would not be maintainable. The
current "security fix or major bump" motto is supposed to be enough in
most cases (as long as software authors use library versions in a sane
way), but a package can still specify a more restrictive requirement, e.g.
when a minor bump of a library introduces a new functionality that the
> | The dependency versions are again bookkeeping issues, this time to
> ensure| that binary packages with wildcard dependencies will work
> Binary packages shouldn't have wildcard dependencies - a binary package
> gets compiled against some particular version of its dependencies, it
> should record which particular version that is, in any case it cares at
> all(there probably needs to be two different kinds of dependencies, one
> for"I need perl installed", and one for "I am using version X of this
Well, that's again another debate, and would require quite an overhelm of
pkgsrc. Right now we need buildlink to handle dependencies that way, and
we can't afford to require the rebuild of everything and its mother all
> email@example.com said:
> | With the ?= assignment, package A could assign BL_DEPENDS.xxx
> xxx>=2, and| then package B (in the order of bl.mk inclusion) assign
> BL_DEPENDS.xxx| xxx>=1
> package A should never see, nor care about package B's depends - if A
> depends upon B, then B exists when A is built/installed, and all of B's
> dependencies must have been satisfied already, there's no need to go and
> do them all again. This is true for both pkgsrc and binary packages.
> The only thing that matters are the things A itself directly depends
> upon, all the rest is taken care of - and for that, there's just one
> version required of each dependency.
Say you're buildling X (let's choose another letters so we don't get
confused), which depends on Y and Z. Both Y and Z depends on W, with
different requirements (it might happen, I gave an example earlier). The
most restrictive requirement must be recorded in order to have X working
(and sometimes even *linking*) properly.
> These problems all come about by including the BUILDLINK_DEPENDS lines
> in every buildlink.mk file - if there were none in any of those files,
> only in the various pkgsrc Makefiles, none of these problems would be
But still, you agree we need them even if only for security
> Next, with this new world order, how do I explicitly override the
> BUILDLINK_DEPENDS line in a buildlink3.mk file? I do that quite often
> in practice (or did, until now).
in the Makefile, just like with bl2. Then, later buildlink3 inclusions
will add (+=) other requirements, usually less restrictive, which will be
ignored in the end. But in the case somewhere in the path a package
requires foo>=1.2.4, thanks to += it will get recorded.
> That is, some very popular package A, was upgraded for some reason that
> doesn't concern me, so I ignore the update (perhaps a bug for some
> architecture that I don't use was fixed, or it was made faster, or ...).
So this is rant about tiff?
> everything. No way. So, instead, I just get C's makefile, and
> add a BUILDLINK_DEPENDS.A=old-version and start again. C is now happy
> to use the old version of A (C's makefile should have always had such a
> line in it IMNSHO).
> What's the method to accomplish this in the new scheme?
Well, now that pkgsrc has been made safer on that issue, I don't know.
Maybe a way to force a dependency regardless of what everything else
actually requires could be provided, but that would be a dirty hack. At
that price, it's as bad as doing 'make replace' for the new A, since
you're the one making the decision that C is ok with A.
Quentin Garnier - firstname.lastname@example.org - cube@NetBSD.org
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.