I'm not thinking in terms of scripting and the like, I'm thinking in terms of information. Like... "oh this needed mysql-libs to build, so maybe it has mysql support"
I don't think it would be all that useful in that case. You wouldn't query the database to find all packages that might have mysql support. If you were interested in that you would probably have a few apps in mind the features of which you would like to compare. If you're trying to determine if an app supports what you need, you would check the website or the manpage, wouldn't you? As pacman would have no direct use for the makedepends, I don't think it would be worth adding them to the database. To achieve what you've just mentioned, adding some sort of tag support would make more sense and be far more useful. I don't actually support that idea though, but listing the makedepends as currently suggested would effectively create a glorified tag system with restricted input. Perhaps another solution would be to convert the abs tree into a third database alongside sync and local. It would be completely optional as abs currently is but once installed pacman (or another binary built for that purpose) would be able to query it for such things as makedepends in a format similar to the current sync and local queries. It would also make it possible to seemlessly build files from source with dependency resolution. Maintaining the database itself is not an issue as the abs tree already exists. Distribution would require archiving each package's PKGBUILD and local source files for distribution on the mirrors similar to the way binary packages currently are (which would take a load of the current abs server and be far smaller than any of the binary repos). The database archive itself would contain files with information extracted from PKGBUILD in the same format followed by desc and depends files in the sync and local databases (including information such as makedepends, optdepends, sourceURLs, etc).