Subject: Re: SOC project proposal: easy updates
To: Julian Coleman <email@example.com>
From: Jeremy C. Reed <firstname.lastname@example.org>
Date: 03/15/2007 12:04:17
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
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