Subject: NetBSD updating system
To: None <>
From: Elad Efrat <>
List: tech-userlevel
Date: 11/06/2007 22:00:01

Recently I have brought old code I wrote to an "alpha" (read: should
work) stage where I'd like others, if interested of course, to test
it and comment on whether they want to see it progressing or not.

The program is tentatively called "haze" (like purple haze) and can
do many things. I'll try to cover most of the stuff here... but I
really suggest to just download, build, and play with it (preferably
in a virtual machine or something).

Everything said below is about the *current* state of the code. Of
course that with little effort it can do many more things. :)

Where to get the code:

How to build the code:


What it does:
Offer a system to generate binary updates for NetBSD (NOT patches),
install, remove with full "rollback to previous state" support, and
manage them. Simple dependencies are allowed. It also allows
auto-generating security advisories from update data.

Without further ado, here's how to use it.

Update producer: (people who *create* updates)

   1. Write the .plist file to describe the update, and put it online.
      Update the index file to include the update id. (for example,

      Examples for updates are available:

      The index file looks like this:

      Note the directory hierarchy: the year is important; everything
      else can be tuned, but the structure. For now.

   2. Maintain a build directory for ports you want to generate updates
      for. This is "obj-dir" in the config file (/etc/haze/haze.conf):


      Haze knows to replace "%m" with the machine type. The default is
      "/usr/obj/%s-%r/destdir.%m", where "%s" will be replaced by the
      string "NetBSD", and "%r" will be replaced by the release, for
      example, "4.0".

      To keep this directory up-to-date, all the producer has to do is
      run the build after the source is updated with the fix.

   3. Maintain a list of "targets" you want to monitor. Haze calls a
      combination of OS-release-machine a "target". For example,
      "NetBSD-4.0-amd64" is a target. By default, Haze will only generate
      updates for the host it runs on. You can override that, though:


   4. After the new files are built, generate updates. This is done using
      the -G flag. For example, if you just rebuilt for
      NetBSD-UP2007-0001, and want to generate updates for it:

	haze -G -U NetBSD-UP2007-0001

      The updates will show up in the output dir, /tmp by default, and
      will be in the form of NetBSD-UP2007-0001-4.0-amd64.tar.gz.

   5. Put the updates online, in the Updates/ directory. For example,
      this would be a valid URL to an update package:

Update consumer: (people who *apply* updates)

   1. Make sure there's a /etc/haze directory and that it's writable by
      the user Haze is running as. I would elaborate on this too much,
      but you *should* be able to tell Haze to perform updating on a
      specified root directory, and then do the sync yourself, if you
      don't trust running Haze as root. If you do:

	# mkdir /etc/haze

      Everything else, including the configuration file and local
      database, will be created by Haze automagically. You can inspect
      the default values used in haze.h.

   2. By default, things should pretty much Just Work. Therefore, here
      are some usage examples:

	Show the batch of updates waiting to be installed:

	  haze -B

	Install all pending updates:


	Show locally known updates (including installed, ignored, and
	not applicable updates):

	  haze -L

	Install a specific update:

	  haze -U NetBSD-UP2006-0001

	Rollback an update:

	  haze -R -U NetBSD-UP2006-0001

	View details about an update:

	  haze -V -U NetBSD-UP2006-0001

	Explicitly ignore an update:

	  haze -i -U NetBSD-UP2006-0001

	Operate in dummy mode, and just print stuff you'd do:

	  haze -x ...

	Generate a security advisory skeleton for an update:

	  haze -S -U NetBSD-UP2006-0001

	List available command line options:

	  haze -h

The code is in very early alpha stages. It did not go through cleanup
yet. It also does not have a worthy man-page, nor does it have many
features that it should. To top that, it only offers binary updates.

Yes, it's likely that this haze will be obsoleted by syspkgs.

However, the idea is simple: if people like it and want to use it,
you now have a BSD-licensed base to develop on top of, and someone to
bug about things you want added. The basic functionality of updating,
managing updates, rolling-back, dependencies, generating the updates,
and generating security advisories exists. Extending, modifying, or
otherwise improving is more than welcome.