[2918] in SIPB_Linux_Development
Re: Installing PUBLIC=false
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Aug 24 14:41:58 2000
To: Greg Hudson <ghudson@MIT.EDU>
Cc: linux-dev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 24 Aug 2000 14:41:36 -0400
In-Reply-To: Greg Hudson's message of "Thu, 24 Aug 2000 10:36:53 -0400"
>>>>> "Greg" == Greg Hudson <ghudson@MIT.EDU> writes:
Greg> Just processed this:
>> We kept coming up with cases where this produced the wrong
>> behavior. It could replace the kernel the installer had
>> installed, which would be a significant disadvantage. It might
>> interact badly with other packages that the installation had
>> chosen.
Greg> If you are going to be creating machines with different OS
Greg> packages installed than the Athena set, I think we will
Greg> become Very Grumpy unless you call them layered machines.
Greg> Part of the definition of a non-layered Athena machine is
Greg> that Athena manages the OS installation. There can be local
Greg> customizations, but they need to be actually be local
Greg> customizations, not "I got a different set of RPMs because I
Greg> used this other installation."
It certainly was not my intent to imply that we wanted to have a
different package set simply because you used a different install. We
are concerned that you may end up with a different kernel package for
example. Also, if the user picks custom, they may end up with a
significantly different set of packages.
If the user picks custom in the Redhat install, do you want the machine to be layered? What
specifically should be true of a layered machine? There are a lot of
things that are different between a layered machine and an IS
installed machine. No /etc/athena/version, init level 2 by default,
etc.I am not sure which of these are artifacts and which should be maintained.
