[1680] in SIPB_Linux_Development
Re: Making system packs an option in the RedHat 4.2 install procedure
daemon@ATHENA.MIT.EDU (Aaron Ucko)
Mon May 26 22:30:53 1997
To: Salvatore Valente <svalente@MIT.EDU>
Cc: nygren@MIT.EDU, linux-dev@MIT.EDU
From: Aaron Ucko <amu@MIT.EDU>
Date: 26 May 1997 18:52:16 -0500
In-Reply-To: Salvatore Valente's message of Mon, 26 May 1997 15:30:50 -0400
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.
Yes, but with your system whoever fixes "jot" has to remember to update
the appropriate package. My system involves less work for maintainers.
> 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.
People who run "jot" out of /srvd only lose before spm updates
symlinks, which should probably occur during reactivation. Updating
files should NOT occur automatically; otherwise, people who modify the
local versions will lose. (Perhaps there should be a way to tell spm
to update only non-modified packages?)
> 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.
We don't have to make sure everything is listed; spm would support an
'everything' pseudo-pseudopackage. We still probably ought to list
everything, though...and spm _would_ have to be written and debugged.
> Oh well. Either one will work. I don't have a strong preference.
You raised some good points; I'm starting to think it might be best to
stick with rpm after all. Anyway, we can discuss this at our meeting.
(When should we schedule it? I should be completely free from June 9
to June 16, and all evenings after that.)
--
Aaron M. Ucko (amu@mit.edu) | For Geek Code, PGP public key, and other info,
finger amu@monk.mit.edu. | "Kids! Bringing about Armageddon can be dangerous.
Do not attempt it in your home." -- T. Pratchett & N. Gaiman, _Good Omens_
