[Rule-list] Installer issues

[Chris Kloiber]

On Sun, 2002-02-10 at 10:42, Marco Fioretti wrote:
> On Sat, Feb 09, 2002 21:01:48 at 09:01:48PM -0500, Chris Kloiber wrote:
> > 
> > Unless you want to burn cycles backporting many needed things (I'm
> > thinking iptables for starters) stick to an Official Red Hat kernel.
> 
> Excellent point. Starting from an official kernel, however, which
> settings could we adjust to make it work more nicely on low-end HW?

Install the stock i386 uniprocessor kernel for the widest hardware
support. Other, more advanced kernels can be added later. The Red Hat
stock kernel is heavily modularized, so it should already be as freindly
as possible to low end machines.

> > I was thinking that the easiest thing to do would be to have an
> > installer that only partitions, formats and mounts the hard drive, then
> > copies a very small (basically an i386 kernel, glibc, rpm, rhn_register,
> > up2date, a shell and any other required things) installed image to the
> 
> I am fine with this, and have the feeling that this is already the way
> we are going anyway, judging by the more specialistic messages here.
> 
> > drive. Then the user can boot into that, register with Red Hat Network
> > and install anything he/she wants with up2date, which can handle
> > dependencies as needed.
> > 
> This must be possible for upgrades and further customization of course, but
> not be part of  the installation itself ( by "installation" I mean modified
> installer + kickstart + whatever post-install script(s) are needed).

Unfortunately up2date requires a net connection. Anaconda can handle
dependencies (for the upgrade case) but it not available outside of the
install. On the upside, there is the rpmdb-redhat package which contains
a list of all the files installed by each package available on the cd.
By installing this you can query the rpm database to determine
dependencies.

> That process must work even when only the RH CDs are available, and put in the
>  PC all the packages that we will find needed for basic desktops. The
> main reason for this is that, as I mentioned somewhere else, most of
> the functionality is achieved by installing on disk standard rpms
> (mutt, procmail, emacs.....) and then rewriting their config files so
> that all these tool work from the first moment at max speed, connected
> to each other. If we put a connectivity dependent phase in the middle
> it will complicate the whole process.

Huh? Why do you want to munge the default configs and scripts? It seems
that way lies maddness (and alot of brokenness when you later upgrade) I
don't see anything wrong with procmail's defaults, although I admit I
don't use either mutt or emacs. I'd suggest you file request for
enhancements in bugzilla for the defaults you want.

-- 
Chris Kloiber, RHCE
Enterprise Support
Red Hat, Inc.


_______________________________________________
Rule-list mailing list
Rule-list at mail.freesoftware.fsf.org
http://mail.freesoftware.fsf.org/mailman/listinfo/rule-list