Here's yet another g2k16 hackathon report, this one from Antoine Jacoutot, who writes:
The one thing I wanted to work on or rather talk about during that week was
having a way to provide binary updates (both for the base system and packages)
to ease maintenance of OpenBSD fleets. While it's perfectly possible to build
your own stable releases and packages, it's a work that could be done centrally
instead of having each and every user come up with his own solution. Plus that
would mean we could get official signed updates.
To be honest, I was expecting some reluctance since it would mean a change in
our workflow but Theo has been very opened to the idea as long as it's done
properly and is up to OpenBSD standards.
So robert@ and I started hacking on it, we kind of knew how we wanted things to
be done since we've been doing a similar thing in M:Tier for years outside of
the official tree along with jasper@. Robert worked on the build infrastructure
(to create the actual binary patches) and my chore was to write the utility that
would fetch, verify, install and eventually rollback these patches.
Binary patching is a complex subject so we wanted things to be baby simple.
Actually "binary patching" is not what we will really do here (i.e. it will not
be a binary diffing/patching utility).
The first bits are in and this is how we would like things to work eventually:
- fetch the tarballs containing the updated binaries/kernels/files
- verify them with signify
- create a rollback tarball containing the installed files that are about to be
- extract the syspatch tarball to a temporary directory
- safely install(1) the extracted files on the system
- if something goes wrong or if a patch introduces a regression, rollback using
the tarball we've created above
That's pretty much all. We are not going to implement things like rollbacking a
particular patch (but only the last installed one) because the goal is to be
synced against stable and not running a Frankenstein system (patches are
cumulative and some may depend on others).
Once we have syspatch in place, we can start looking at offering binary
packages updates for stable (all the build infrastructure is of course
already available, so that's just a matter of integrating it in our stable
Besides that, I've worked on a few corner cases that our rc.d(8) does not cope
well with. That's not committed yet because it requires a bit more work and
beck@ gave me a couple of other ideas that I'd like to implement at the same
So stay tune for upcoming changes...
Of course, I took a ride under ports/ for a while, adding some USE_WXNEEDED bits
here and there (unbreaking gnome-shell and gdm) and jasper@ offered me the huge
honor to remove devel/glib (i.e. glib-1.X!) from the tree. I updated a few
things as well and sync the login_krb5 port to match some recent changes in
One night, fill with boredom^beer, jasper@ and I went to portroach.openbsd.org
(which lists outdated ports in the tree) and started an update rampage
All in all it was again an amazing week amongst amazing people!