The current trend seems to be on the tools getting tighter checks. More specifically, it doesn't help a lot if you build a package, and later on discover you can't install it, or can't update your system.
- some misuses of features have been correctly (like manually inserting some keywords in plists which are deduced by the framework, e.g., @symlink). I'll probably do some similar check with @sample, as inserting a @sample at the top of a plist is bound to lead to head-scratching... - a few months ago, we turned on register-plist by default: all porters use that tool to keep a database of packing-lists, indexed by FULLPKGNAME. Whenever you build a package, if the FULLPKGNAME didn't change and the plist doesn't match, you're in trouble: someone did not bump a version. - since pkg_add -u now fully recognizes version numbers, register-plist got some improvements: it now "updates" dependencies. Namely, if a FULLPKGNAME didn't change, version numbers of all dependencies are allowed to go forward (that's the way signatures work after all). This does catch a few errors in dependencies... for instance, it's responsible for the openoffice EPOCH bump this morning. - I intend to go a bit further, and check that FULLPKGNAMEs go forward directly. The above change only catches problems in version numbers "accidentally" thru dependencies. It shouldn't be too hard to do the same directly. - LIB_DEPENDS and WANTLIB interactions are still hard to grasp for some people. I'll admit the semantics are not quite intuitive, but they're there for good reason. Once again: a LIB_DEPENDS will *only* create an actual @depend in the package if it contains a library that's needed as one of the @wantlib. No dependency chain there. You can't put a LIB_DEPENDS = x11/gtk+2 if you don't actually use one of gtk-x11-2.0, gdk-x11-2.0, gailutil. It will vanish, and you won't get access to glib and friends... - thus pkg_create got smarter. I'm taking apart the Dependencies code used during pkg_add for reuse in there (and it's going to help check-lib-depends too eventually). pkg_create used to be able to create packages you wouldn't be able to install later (with pkg_add complaining about dependency chains, not finding libraries, or not finding dependencies). Now, pkg_create will refuse to create the package. Of course, this comes at a price, namely pkg_create may now need to ask the ports tree about packing-lists... I'll make sure to provide a way to disable this if people want to use pkg_create directly. - not directly related, but reliability improvement nonetheless. I hunted down and fixed a race condition in ldconfig/ld.so which would make bulk builds flaky. Specifically, if you were to have several concurrent builds on the same machine, there was a chance an ldconfig from a pkg_add would erase its hints file precisely while ld.so was trying to locate a shared library, thus leading to sporadic failures (roughly 2 or 3 over a full bulk on one of my test machines). All those changes should make things vastly more comfortable for porters. (or should I say, most specifically to the few brave souls that do bulk builds and ensure everything still works as it should). Since errors occur much earlier, you get a chance to fix them on-the-spot, instead of having to rebuild huge chunks of the tree after figuring out something much later did break. A lot of those things are work-in-progress. Dependencies changed some much during the last few months, along with readmes, groff removal, @rcscript, that there are some corner cases that only hold together barely right now. Things will get better...
