Re: Introducing the patchadd binary patch toolchain

[Elad Efrat <elad%NetBSD.org@localhost>]

On Wed, Apr 29, 2009 at 8:28 PM, Quentin Garnier <cube%cubidou.net@localhost> 
wrote:

> In the end, it is up to the people who will be doing the arguably hard
> work (no matter which tool is used for the job) of producing the binary
> updates.  I would say those people are releng@ and security-officer@.

I am aware of that. In fact, that was a design goal for me, and if
you'd read my email about haze you'd notice I first address it to
"update producers".

I'm not too familiar with the releng@ work, but an annoying part of
security-officer@ by what I've seen is producing the security advisory
(communicating about the bug with the reporter/upstream, or fixing it,
can obviously not be an automated process).

> Given the total lack of history of binary updates in NetBSD, my very own
> opinion is that any such tool should be focused primarily on making the
> production of binary updates as easy as possible.  I'm fairly certain
> the users will agree with pretty much anything that will give them
> binary updates they can install and roll back with sustainable pain.
>
> I think the main risk is at the production level.  If it is not easy
> enough, it will be too much for the time releng@ and s-o@ have.

There are more "risks", but let me paste item #4 for the producers
from my original email:

   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.

The process, unless obvious, is like this:
  1. Write the description of the issue -- mostly just the stuff
that'd go into a SA (or use a tool to generate it)
  2. Fix the issue in the code, run the build (or have the autobuild
do it automatically, or whatever)
  3. After the build finished, run a single command (that can probably
be attached to the autobuild very easly)

> So I'd very much like to see this discussion turn towards the way the
> tools (any of them) can be used by releng@, e.g. how they can be tied to
> the autobuild system, and so on.  This is what matters most to me.

See above. I don't think it should be that hard.

All that said, we're once again "deciding" on something without
hearing opinions on it. When I wrote my tool I didn't support binary
patches (as opposed to just binary updates that include the replaced
object rather than a patch for it) because I don't think we should.
While it's great to have a tool that releng@ or security-officer@ can
easily work with, a part that's just as important is what users are
looking for.

-e.