Subject: Re: Managing lots of installed packages, buildlink and versions
To: Martin J. Laubach <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 05/19/2002 20:34:57
On Sun, 19 May 2002, Martin J. Laubach wrote:
> | I'd like to see everything out in the open, too, but I don't see that
> | happening.
> So let's tackle this from the other end -- if foo says in its
> README (or whereever) that it needs bar 1.3 or higher, would anything
> break if one added a BUILDLINK_DEPENDS on bar >= 1.3?
It could, yes. If the soname (major) of a shared library in "bar"
changes with "bar-1.4", then you've got to decide if you want to build
against the old "bar", or the new "bar".
> For source package builds, this looks begnign. For binary packages,
> the dependency is on exactly the version currently installed, so there
> is no harm done there either, is there?
> I'm probably overlooking something obvious?
Well, for most of the packages affected by the "png" bump, it wouldn't
have made any difference. "buildlink.mk"'s aren't the only source of
hidden dependencies. A magicfilter-1.2nb2 package I just made, for
example, has a dependency on png>=1.2.1 by virtue of the dependency in
the installed "netpbm" package, not because of anything (that could be
changed) in "pkgsrc". At least, it's only "nb1" and "nb2" that carry
the baggage, so someone who wasn't ready to upgrade "png" could still
install magicfilter-1.2, and there's no danger of that being
overwritten, now that it's not the latest anymore.