Re:[Rule-list] Installer issues

[Marco Fioretti]

> 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.

OK with me


> 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.

Sounds promising! We really should not count on a net connection at
that stage. FWIW, I (with two computer at home) found myself SEVERAL
times with the computer under install with no networking/modem/pppd
working, etc. and the modem hooked to the other one so I could browse
the net and ask for help...

For example, I have NEVER been able to set up an internet connection
at install time with any version of RH (of course the problem might be
just me, but still....)

> > 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
......
> 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)

Absolutely. I just didn't explain myself correctly. I meant:

1) install standard rpms, defaults and all
2) substitute/create USER rc files, for all users created during install
3) Write big and clear somewhere that we did point (2)

This works for user applications: $MY_HOME/.muttrc, $WIFE_HOME/.muttrc
and such don't mess with anything else or with upgrades, do they?

Servers are different beasts, of course. xinetd.conf, /etc/postfix/main.cf, and 
so on.

Still, if we :
0) install them from standard RPM
1) save the original rc files (NOT BINARY/LIB ONES, of course)
2) replace them and them only with ones OK for "OUR" idea of default use
3) (again) document the whole thing

what is the difference w.r.t. the case where we go personally to the
guy's desk, and help him to reconfigure by hand the rc files? Would
it still breaks so many things (more than it would to any of us that
ever customized any .conf file, I mean)?

Going upstream  to convince application or package developers that our
idea of defaults is the Right One for everybody, *that* seems like hell
to me, even if one were sure of it: sounds almost like forcing a VI user
to go emacs, or viceversa....

        Ciao,
                Marco Fioretti