The basic problem is that if A requires B.y, and B.x is installed, then
after you "pkg_add -u"/"make replace" B, then C which was linked against
B.x needs to be upgraded (in the general case, can be omitted if B.x and
B.y ave the same ABI).
As far as I know there is only one fundamental strategy to deal with
this, which is to have all packages from a consistent build of the
control files.
With pkgsrc stable, you jump from one branch to another. ABI changes
are simply not allowed within the branch. My understanding is that
designated releases of GNU/Linux distributions (e.g., Ubuntu Feisty
Fawn) are equivalent to a pkgsrc stable branch.
Given the above, there are 3 sound update strategies:
binary upgrade of everything from a published bulk build
binary upgrade of all of your packages from a bulk build done by you
(only needs to build what you need)
source upgrade, of which there is make update and make replace, and
pkg_rolling-replace to do the make replace method in the right order.
Note that "update strategy" refers to what you do after changing your
pkgsrc source reference point. This can happen by
switching branches: cvs up -r pkgsrc-2010Q4
updating to current: cvs up -A, or just cvs up
I'm not sure you've really said, but I think what you've done is
get pkgsrc as of some date
build a bunch of packages
wait a while
update pkgsrc to head via cvs up -A
[missing step]
try to build another package
For the missing step (since you must be using head or you wouldn't be
talking about pain caused by png), the only feasible options are binary
update from a bulk build you did yourself and pkg_rr.
I am not aware of any GNU/Linux package manager that lets you do the
above without having some mechanism that's like the update steps I'm
talking about. Most users at least of GNU/Linux seem to only do binary
updates from official published repositories.
Did you try 'make replace' in x11-links? Did you try "pkg_delete
x11-links"? It's generally only a build dependency so that should work.
If on the other hand you have left pkgsrc where it was from your
original checkout and tried to build a new package, it very likely would
have worked, and if you were on a stable branch the odds are very high.
So basically, if you don't want to be on the bleeding edge, use the
stable branches. But pkg_rr is not that hard to use, and newer package
managers that will automate the bulk build process even more are being
developed. Even now, doing bulk builds of a list of pacakges is not
that hard. But it's harder than using published full bulk builds from
stable branhces.