[1683] in SIPB_Linux_Development
Re: Making system packs an option in the RedHat 4.2 install procedure
daemon@ATHENA.MIT.EDU (Derek Atkins)
Tue May 27 11:25:09 1997
To: Salvatore Valente <svalente@MIT.EDU>
Cc: amu@MIT.EDU, nygren@MIT.EDU, linux-dev@MIT.EDU
From: Derek Atkins <warlord@MIT.EDU>
Date: 27 May 1997 11:24:48 -0400
In-Reply-To: Salvatore Valente's message of Mon, 26 May 1997 15:30:50 -0400
There are at least two problems with using _just_ RPM. First, RPM
does not deal cleanly with having two RPMS containing two different
files of the same name. In other words, RPM does not handle
/usr/athena/bin/jot being a file in "misc" and a symlink in
"srvd-misc".
Second, there isn't a good way to set this up on the install server.
The redhat install program automatically creates an "everything"
package, which would try to install both "misc" and "srvd-misc". The
first RPM to get installed, in this case "misc", would win out and
everything in "misc" would get installed locally. However,
"srvd-zephyr" would be installed before "zephyr", so that would fail.
Worse, the user would receive an error message for each duplicate RPM.
I personally prefer the "spm" model better. We can reduce the Athena
installation to two RPMS: AFS and Athena, where "Athena" contains
enough information to get spm up and running, and then it can run spm
to install everything else. Indeed, spm could probably even use
"synctree" if we wanted to be consistent with standard Athena.
This would mean that there is a two-stage install: The Linux install
(which installs AFS and "Athena"), and then the Athena install, which
runs spm as part of the athena.init and installs the rest of the
packages.
The hard part is figuring out how to let the user define which Athena
pseudo-packages she wants installed at install-time.... And perhaps
the way to do this is using the multiple-RPM method and make sure that
the 'first' RPM is "put everything local" so that an "everything"
install will DTRT. This would mean that a user installing
"everything" would see an error for the Athena-package-list RPMs,
which is probably ok.
-derek
PS: I think having a tool like spm would be useful. I wonder how much
of "mkserv" we can borrow for spm?
Salvatore Valente <svalente@MIT.EDU> writes:
>
>
> Aaron wrote:
>
> Sal's model makes some sense, but also means we still have to worry
> about making sure every file is in a package and about issuing new
> versions of packages when we make changes. I've been thinking of a
> different model, which replaces those problems with different ones.
>
> Your model's neat. But I don't think it replaces the problems with
> different ones. As far as I can see, it has the exact same problems:
>
> Problem 1: Say a bug is fixed in "jot". People who have "jot" local
> need to upgrade their binary, but people who run "jot" out of /srvd
> win.
>
> Solution: With my system, some people have to run "rpm -U misc". With
> your system, some people have to run some spm command. In either
> case, the reactivate script (or something) can be hacked to notice the
> new package (or whatever) and update it automatically.
>
> Problem 2: Say a bug is fixed in "jot". With the fix, jot now reads a
> new file at runtime, "/usr/athena/lib/jot.conf". People who have
> "jot" local don't get the fix, and people who run "jot" out of /srvd
> lose completely.
>
> Solution: With my system, everyone has to run either "rpm -U misc" or
> "rpm -U srvd-misc". With your system, everyone has to run some spm
> command (except people who have absolutely nothing local and make
> /usr/athena a symlink to /srvd/usr/athena). In either case, the
> reactivate script (or something) can be hacked to update
> automatically.
>
> Problem 3: Maintenance. In either system, we have make sure every
> file is listed in some .spec file or equivalent. With my system, we
> have to create new packages after changing something in /srvd. With
> your system, we have to make sure spm works.
>
> Am I forgetting stuff?
>
> Oh well. Either one will work. I don't have a strong preference.
>
> -Sal.
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
