recap of ports infrastructure changes

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

recap of ports infrastructure changes

Marc Espie-2
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...