[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Introducing the patchadd binary patch toolchain
On Wed, Apr 29, 2009 at 8:28 PM, Quentin Garnier <cube%cubidou.net@localhost>
> 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
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
Main Index |
Thread Index |