Re: SOC project proposal: easy updates

At Thu, 15 Mar 2007 12:04:17 -0500 (CDT),
Jeremy C. Reed wrote:
> 
> 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?

I think there is already a really simple way to do this, at least given
certain caveats.

My idea for a long time now has been to use incremental "build.sh -Uu"
builds and the METALOG file to create binary "update" distribution sets.

I already have my builds inserting comments into the METALOG file so
that I can see which files were installed by each subsequent build using
the same DESTDIR.

The list of updated files could be easily separated into different
groups corresponding to each of the current binary sets archives.

I.e. "build.sh -Uu distribution" would then generate both full binary
sets files as well as binary update sets containing just those files
installed by the most recent run.

Syspkg support could no doubt also be added if desired.

The obvious caveats include always using "build.sh -U", keeping a set of
full master build directories around for each release so that subsequent
"build.sh -U -u" runs will produce the desired results, and of course
assuming that anything that changes DESTDIR will be recorded in the
METALOG file.

Until recently I didn't have enough available storage space to do this
for my builds so as yet it's remained just a conceptual specification in
my notes, but if I can get my build platforms stable again with the
storage space I expect to be able to connect to them then I might be
able to finish the missing implementation.


Taken to the extreme this would be very similar to how IBM distributed
update tapes for AIX (and presumably many of their other OS products).
I haven't seen them in over a decade, but back with AIX-3.2 they would
send out a tape (or several) with sequentially appended sets of archives
that would take a system from its current level to the desired level,
including updates for specifically requested bug fixes.  They didn't
even bother merging the update sets to remove files that would be
replaced again by subsequent archives on the same tape.  I remember one
update consisting of at least 2 8mm tapes that unpacked at least a dozen
copies of the kernel alone, but they were all in the right order and the
end result was a system updated with the desired fixes.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <[email protected]>
Planix, Inc. <[email protected]>       Secrets of the Weird <[email protected]>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: cdsR/3Nc2iHiTPfi4QwRhngFm/Kne0wI

iQA/AwUBRfr8eGZ9cbd4v/R/EQKLbQCg2BQatOhPR7vE2p0fnZ6vFb+dRi4AoIxa
/5wrSOjaH1sj6HGKL+N+SZAP
=BG0f
-----END PGP SIGNATURE-----