Contributed by rueda on from the bin-bin-bin-patches! dept.
This was my first time in Cambridge and I must say I really enjoyed the place. It's a gorgeous town and avsm@ and Gemma's organization of the hackathon was just perfect. So first of all, thank you very much to them and to the OpenBSD Foundation.
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 replaced
- 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 update workflow).
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 time. 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 base.
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!
Thanks for the report, Antoine!
(Comments are closed)