[2921] in SIPB_Linux_Development
Re: Installing PUBLIC=false
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Aug 24 16:02:16 2000
To: Greg Hudson <ghudson@MIT.EDU>
Cc: linux-dev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 24 Aug 2000 16:01:56 -0400
In-Reply-To: Greg Hudson's message of "Thu, 24 Aug 2000 15:31:03 -0400"
>>>>> "Greg" == Greg Hudson <ghudson@MIT.EDU> writes:
Greg> I'm getting a bit of disconnect between what Sam is saying
Greg> and what Derek is saying. Derek seems to want an install
Greg> which works with all hardware but is as simple as possible;
Greg> Sam seems to want to let the user do some customizations
Greg> during the install.
I think that is because warlord and I haven't talked, and as far as I
know his message was the first anyone working on the project knew of
his goals.
>> We are concerned that you may end up with a different kernel
>> package for example.
Greg> As far as I know, SMP systems are the only example of this
Greg> problem. We can make the Athena install/update take SMP
Greg> into account if that's the only issue.
OK, apparently I was confused. I'll talk to others involved and make sure this problem won't pop up.
>> If the user picks custom in the Redhat install, do you want the
>> machine to be layered?
Greg> This dependson the interface "custom" presents to the user.
Greg> If it amounts to "the user making tweaks to the Athena list
Greg> of RPMs," then it can be an Athena machine, since the
Greg> package differences are conscious local modifications. If
Greg> the user loses all indication of whether an RPM under
Greg> consideration is in the standard Athena list, then it should
Greg> be considered a layered machine.
Understood. We will comply; I'm not sure which option is easier for us.
>> What specifically should be true of a layered machine?
Greg> For a layered machine, /etc/athena/version should have a
Greg> version number of "Layered" instead of an Athena version
Greg> number. Other than that, I think we don't particularly
Greg> care.
Thanks much.
