tech-userlevel archive

[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 09:02:33PM +0300, Elad Efrat wrote:
> > 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)

Why didn't anything happen?  And please don't take that personally, but
if a tool easy to use to do binary updates existed two years ago, why
isn't it in use right now?  One thing I trust Tonnerre on is that he
will try to go all the way and do the necessary pushing on releng@ and
maybe admins@ to make the thing actually happen.  Not everything is
about technical merit or user experience.

> > 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.

That's an implementation detail, as far as I am concerned.

> 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.

Well, duh.  But if said users only get to use it every 10 years it's not
that useful.  (Yeah, I know, duh too.)

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgptpXogLqg2E.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index