OpenBSD Journal

Binary Patches Project

Contributed by jose on from the begone-patch-&&-make! dept.

Gerardo Santana Gómez Garrido has been working on binary patches for the masses as one of his projects. As noted on the website, "there are special cases where the administrators don't have the resources" to download the source code and recompile. As such, binary patches may suit their needs as an alternative method for keeping systems up with software fixes. Special cases pop up, though, for libraries (ie libc fixes ) and staticially linked binaries that use them or API changes.

This project is highly experimental and shouldn't be applied to production systems without heavy testing for your environment. However, if it works for your needs it promises to be quite useful as another option for keeping up to date.

(Comments are closed)

  1. By Noryungi () n o r y u n g i @ y a h o o . c o m on

    A couple of questions:

    • If OpenBSD is such a functional system, how come people cannot compile patches on some systems? That does not make any sense, especially since it's supposed to work well, evenon low-end machines...

    • Given the OpenBSD audience (paranoid sysadmin), how come this guy thinks they are going to use his binary patches, instead of the source downloaded direct from Again, that does not make a lot of sense... Add to this the small number of patches released for every new version, as well as the small size of the patches, and you have a contradiction in terms.

    A nice idea, but I am not sure it's going to go anywhere.

  2. By Anonymous Coward () on

    The lack of binary patches has always been a royal pain in the ass. Application of binary patches to releases would be most elegant if it were integrated into the pkg-add system.

    I find it a nuisance to have to keep 400 MB or so of source code on my harddisk, and patching multiple systems is generally a much more ambitious undertaking than it should be.

  3. By Anonymous Coward () on

    There have been other attempts at this, with varying degrees of success. Search the archives for various posts on the topic - I used to maintain a site which laid out all the requirements folks thought should be met with such a system.

  4. By Iain () on

    First a binary patch system would be excellent for the specified small machine configurations. Also the idea of self patch system where you create your own patchs will also been an excellent addition.

    Here is my two cents on the issue.
    1. Must have all files signed by a private key and then be checked with a public key. "Gnu Privacy Guard" will be an excellent tool. Issue is we will need to put this program into the default install. Alternate is to generate a gnupg engine which we could allow the gnupg folks use but we do not use their application layer in the default install.

    2. For compiling packages and upgrades we need both a cross compiler and the ablitiy to build with out using the configuration on the build machine. That is all #include directives point to the source directory of the CVS archive. Second I can specify the version I want built. Example is: make TARGET=sparc on my intel machine.

    3. Another item would be a tool to update configuration files even though the person has customized the config file. Classic is updating the /etc directory.

    4. Last is a ftp site for official OpenBSD signed binary patches. This will be where default builds and configuration files are placed.

    A design document is need so the Core Team can comment as with the rest of the user base.



Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]