I noticed that all your buildlink.mk files include, as a matter of
course, every buildlink.mk file for every package that the buildlink'd
package depends on. This is really, really wrong. It's wrong not only
because it's completely redundant to the existing mechanism whereby
binary packages include recursive dependencies, but it's wrong because
doubling up dependencies can do real harm, unnecessarily shortening the
useful life of the resulting binary package.

Take, for example, "libwww". Libwww requires "openssl" (on systems older
than 1.5), in order to build and install libwwwssl.so*. No package that
depends on libwww>=5.3.2nb1, however, actually links in libwwwssl, yet
all depend on "openssl" by virtue of the recursion mechanism in the
"package" target. Now when you upgrade openssl, or upgrade to 1.5.x, you
can't just rebuild libwww and reinstall the packages that depend on it.
You have to rebuild teTeX, and glibwww -- and therefore gtkhtml and most
of gnome -- even though you will probably get identical binaries to ones
in the (wrongly obsoleted) packages. In this case, including
openssl/buildlink.mk in libwww/buildlink.mk just adds to the insult and
increases the build-time and clutter under work/.buildlink.

Now consider "ee", which depends on lots of packages which it has no use
for -- libxml, Mesa, ORBit, bonobo, glibwww, libwww, and oaf, including
multiple wildcards for libxml and bonobo. None of these are direct
dependencies; they're all complements of the recursion in "make
package", based on the single dependency on "gnome-core". Previously,
you could build this package against a slightly older version of
"gnome-core", or "gnome-libs", and it would still work with the newest
one. The point is, changes to the minor version of "liboaf" and
"libORBit" aren't an issue, since the binary doesn't actually require
them. Now, however, by virtue of recursive buildlink.mk includes, the
package will depend on the very latest version of everything, even
things it doesn't need at all. The package that you then have to go to
so much trouble to build, will not be portable to systems that it should
be portable to, because of these additional (bogus) dependencies.

This is all a big step in the wrong direction. Even a mechanical change
away from that would be good. I mean, if you were to take away all
recursions in the buildlink.mk files, and present all the (formerly)
recursively included buildlink.mk files in the Makefiles, at least the
maintainer could delete the line once he finds it's not actually needed.

Frederick