Subject: Re: CVS commit: pkgsrc/mk/buildlink3
To: Robert Elz <kre@munnari.OZ.AU>
From: Johnny C. Lam <email@example.com>
Date: 01/25/2004 18:44:12
On Mon, Jan 26, 2004 at 04:11:30AM +0700, Robert Elz wrote:
> 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).
> 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 ...). In any case
> assume that what happened was one of those things which does cause its
> BUILDLILNK_DEPENDS to get updated (or did, correctly or not).
> Then some package (B) is upgraded for a reason I do care about, perhaps a
> security fix, or similar. This one I want to upgrade.
> That's fine, I go upgrade B, which requires me to rebuild C, which
> depends upon B. I'm not real happy about the need for this, as I
> believe that B should really just be able to be upgraded without touching C,
> but that's OK, I know how pkgsrc likes to be safe, so I go ahead and delete
> C, and then upgrade B. Fine.
> Now I come to recompile C against the new B, only to find that C is
> now demanding the new A be installed. C was working just fine with
> the old A 15 minutes ago, it would work fine with the old A again if
> pkgsrc would compile it that way - but it won't. I could upgrade A,
> but that one turns out to require me to delete and reinstall almost
> 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?
I think explicitly overriding the BUILDLINK_DEPENDS.<pkg> line is a
workaround for the problem you subsequently describe. Yes, updating
using pkgsrc can suck, and I'm trying to slowly modify pkgsrc to the
point where updating doesn't suck. To this end, I'm trying to do
development on the buildlink3 framework, which is still not widespread,
and I'm working up to changes in buildlink3 that allow a user to
specify that they would like to ignore a particular upgrade requirement
and build against the version of the software that is already installed
on the system. This is like Rene's BUILDLINK_RECOMMENDED.<pkg>, but
tries to work in the way that a user is likely expect (I want to link
against what I already have installed because I don't want to upgrade
that particular package right now...).
I completely understand the situation you're describing above because
we've all undergone the pain of being forced to update some key
packages that we would have much preferred to defer to another time.
I'm just trying to arrive at a better system in increments.
-- Johnny Lam <firstname.lastname@example.org>