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
- 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
- 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.