I've finally finished cleaning the DEPENDS lines to a state I like. A new feature was introduced, but it's rather esoteric, and VERY special case, so I'd advise against using it for very good reasons, it's a new ports variable called PKGSPEC.
Here is what happened before PKGSPEC: ------------------------------------ When you write a dependency line such as: BUILD_DEPENDS = devel/bison there is just a directory name, no pkgspec part, so the pkgspec part is automatically generated. Up until a week ago, it was ALWAYS stem-*, e.g., the above was equivalent to BUILD_DEPENDS = bison-*:devel/bison This is almost always appropriate, and there is very little case for changing it for almost any port. HOWEVER, a few ports can coexist as various versions. For instance, you can install autoconf-2.13 alongside autoconf-2.59. So, what do you do when you need a given autoconf version ? Turns out the following would be incorrect: BUILD_DEPENDS = devel/autoconf/2.59 if no autoconf is installed, then this would install autoconf-2.59. However, this is really BUILD_DEPENDS = autoconf-*:devel/autoconf/2.59 any autoconf would do. So if autoconf-2.13 was already there, then the port would happily continue building, and usually fail in atrocious ways. ------------------------- PKGSPEC is something I can now put in the autoconf/2.59 port proper, I would write PKGSPEC = autoconf-2.59 and suddenly, my BUILD_DEPENDS becomes correct: BUILD_DEPENDS = devel/autoconf/2.59 will be enough to only match autoconf-2.59. This is very powerful: I can now tweak all default dependencies on a port by just adding a line to that port. This is also quite dangerous and very sneaky: when you see a DEPEND like the following, you have no obvious way of knowing whether it's autoconf-* or autoconf-2.59. (okay, if you build it, you'll find out soon enough). So it should be used very seldom. For the few cases that require it, though, it simplifies things a great deal. I did "fix things" for: devel/autoconf/* devel/automake/* devel/libsigc++ databases/db/* databases/db/* security/gnupg net/libdnet/* besides simplifying things, this did catch at least ten dependency bugs, where a port would not be specific enough in what it wanted. I see java, tomcat, tcl, tk, python as other potential candidates for PKGSPEC, but I don't know that software well enough to decide, maintainers will have to think about it. (I know that jeremy already decided to use it for ruby). Maybe notification-daemon-* ? I don't know. But most ports out there shouldn't need it. How do the new dependency features interact with pkgnames bumps and revisions ? Well, actually, they don't... everything that matters for register-plist is the final product, where all dependencies are rewritten as @depends and @wantlib lines. So if you end up with a pkgspec that says db->=4,<5 it doesn't matter if it comes from a default or an explicit pkgspec in the dependency. HOWEVER, if you *do* change a PKGSPEC on an existing port, *every* depending port may pull the new default spec, and thus require a bump. So you need to check things very carefully. Like I said, PKGSPEC is not a "simple" feature, nor a feature that should be used in most cases.
