[2920] in SIPB_Linux_Development
Re: Installing PUBLIC=false
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Aug 24 15:31:25 2000
To: Sam Hartman <hartmans@MIT.EDU>
cc: linux-dev@MIT.EDU
In-Reply-To: Your message of "24 Aug 2000 14:41:36 EDT."
<tslu2ca7b8f.fsf@sweet-transvestite.mit.edu>
Date: Thu, 24 Aug 2000 15:31:03 -0400
From: Greg Hudson <ghudson@MIT.EDU>
I'm getting a bit of disconnect between what Sam is saying and what
Derek is saying. Derek seems to want an install which works with all
hardware but is as simple as possible; Sam seems to want to let the
user do some customizations during the install.
> We are concerned that you may end up with a different kernel package
> for example.
As far as I know, SMP systems are the only example of this problem.
We can make the Athena install/update take SMP into account if that's
the only issue.
> If the user picks custom in the Redhat install, do you want the
> machine to be layered?
This dependson the interface "custom" presents to the user. If it
amounts to "the user making tweaks to the Athena list of RPMs," then
it can be an Athena machine, since the package differences are
conscious local modifications. If the user loses all indication of
whether an RPM under consideration is in the standard Athena list,
then it should be considered a layered machine.
> What specifically should be true of a layered machine?
For a layered machine, /etc/athena/version should have a version
number of "Layered" instead of an Athena version number. Other than
that, I think we don't particularly care.
