Re: Introducing the patchadd binary patch toolchain

[matthew sporleder <msporleder%gmail.com@localhost>]

On Wed, Apr 29, 2009 at 2:44 PM, Tonnerre LOMBARD 
<tonnerre%netbsd.ch@localhost> wrote:
> Salut, Paul,
>
> On Wed, Apr 29, 2009 at 10:04:24AM -0700, Paul Goyette wrote:
>> Which begs the admin-question:  even if we have the tools, who in the
>> Project is going to be responsible for defining and creating "official"
>> NetBSD patch-sets?
>
> I am considering a tool to generate the patch in some way from the
> information associated with the pullup request (probably a two-step
> process), but I'm not really sure how to. Maybe Elad has an idea
> there. An alternative would be the source-changes mail...
>
> The rest of the information should probably already be there. It
> might require some processing power to get it out of the existing
> patches though; maybe I should just record a file list in the
> index file which can be used to autosuggest the dependencies.


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.

So if you had a destdir (or your own /), cvs update && build.sh -O
/somewhere you could get the diff from /somewhere and / and generate a
patch from it.  I ran into a wall because mtree files didn't provide
an easy way to track dependencies.

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?)
2) when you change the kernel version, which you would want to do
after patching, you also need to re-create everything in /stand, which
don't seem to make it into an mtree.

Personally, I think the destdir method stands up well in the case of
userland.  The kernel is yet-to-be seen, however.

Matt