On Thu, 15 Mar 2007, Julian Coleman wrote:

> > I'd say that the project should be re-written to propose a port of the
> > existing FreeBSD tools for doing the same thing. There is no good
> > reason to re-invent the wheel.
> 
> Do you mean for both the build side and for the client side?  If so, do
> we need syspkgs - what purpose would they serve?  Or would this be a
> combination of syspkgs and the FreeBSD tools?

This was discussed a lot recently. Some suggested we should just provide 
complete files (such as included in syspkgs) and not binary diffs (like 
FreeBSD's binary updates).

Your proposal says:

   The NetBSD build process should be extended to compare the results of
   the "base" system build (e.g. 3.0) and the results of the "update" 
   system build (e.g. 3.0.1).

Do you have further details on how you'd like this to be done?

As mentioned in the FreeBSD binary updates whitepaper, my Puget Sound 
Technology system just created MD5 checksums for all files of resulting 
install and then compared after patching. Then I manually reviewed the 
changed files to determine if there was any noise. (FreeBSD automates 
this.)

I tarred up the new files and appended to a self-extracting sh script 
that backed up previous files, can roll back changes, list files, and 
give info about the update.

I think we don't need to do binary diffs. But just use syspkgs. Tell the 
users that new syspkgs are available (even in database, like 
pkg_summary(5), or in security announcements) and let the user upgrade 
with pkg_add. (By the way, I have a pkg_add that overwrites files instead 
of deleting existing package and removing files first; I have used it 
hundreds of times for over a year on various NetBSD and Linux systems but 
not recently; most of it is in pkgsrc-wip.)

  Jeremy C. Reed