Re: Introducing the patchadd binary patch toolchain

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

On Wed, Apr 29, 2009 at 10:12 PM, matthew sporleder
<msporleder%gmail.com@localhost> wrote:

> Comparing destdir's is a pretty good way to get differences between
> two builds.  I did it successfully to generate patches in my own
> updating tool.

What are the management costs of always keeping an "old" and a "new"
build? how does it work? each time you run a build something puts the
current build into "old" and the new build into "new?

> I found that the biggest gotcha in the whole process is kernel changes
> for two reasons:
> 1) there are a lot of custom kernels out there (maybe there is where
> binary patching is superior to file replacement?)

I'm sorry, but I don't understand. Are you suggesting that it might be
easier to patch because people might have different binaries?

There was an effort on making sure compiling is "deterministic" in the
sense that you could compare binaries and see no change. Assuming that
happened, how reliable is patching going to be even in that case? what
are you going to do about the people with kernels the patch simply
doesn't apply to because the context differs too much (and that's not
that hard for binary diffing)?

One solution would be to agree that because we can't cover all cases
with custom kernels, or have the means to "measure" to what extent a
custom kernel can be patched (because this is subject to the custom
features used and the patch itself), we ship complete replacements
(say, GENERIC) people can use in the mean time. You could say, "but
what about those where who *run* GENERIC? we can ship patches to them"
-- and then we need to discuss whether we truly prefer patches over
simple replacements, or want them in addition.

And in either case, a tool that can give you the choice to cover
everything (produce both) or use everything (apply patches/updates)
is, to me, superior to a tool that was "designed" for only half the
functionality.

-e.