[2073] in Release_7.7_team
Linux update
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Feb 2 22:56:42 2000
Date: Wed, 2 Feb 2000 22:56:24 -0500
Message-Id: <200002030356.WAA01326@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
So, here is my proposal for a Linux update strategy. A lot of it is
fairly arbitrary.
We'll have sysprefix and syscontrol variables as before. But we'll
have a single control file for each full release. So the cluster info
for a given machine might say something like:
sysprefix=/afs/athena.mit.edu/system/rlinux
control=control/8.3
The format of the control file will be something like:
# Lines beginning with '#' ignored
# Versions must be in increasing order.
8.3.0 rpmlist control/list-8.3.0
8.3.0 script control/script-8.3.0
8.3.1 rpmlist control/list-8.3.1
8.3.2 rpmlist control/list-8.3.2
Using /etc/athena/version, the update script will keep track of which
version the machine is currently at. Packages will be removed if they
are in the list for the old version and not in the list for the new
version, so we don't need separate removal lists. Scripts will get
run for all new patch versions.
The control file for 8.4 would contain all the 8.3 versions plus the
ones for 8.4. (So if we do a patch release for 8.3 after 8.4 goes
out, we have to update the control file for 8.4 as well. No big deal
there, and I don't really want to implement include directives in a
shell script.)
I'll start working on the update script for this plan right away.
Let me know if it seems wrong.
