GNOME Install Wizard?

[james-gnome tainted org]

I'm going to have to disagree with everyone who is thinking that
GNOME is the right place for an "install wizard" application.

The correct place for this is in the underlying packaging
mechanism (be it APT or RPM), for discussions sake, I'll use RPM.

First, some common misconceptions about RPM:

1. You need to use --force to install anything.
2. RPM will break your system
3. RPM is for newbies
4. It's hard to install a directory of RPMs
5. It's hard to upgrade a directory of RPMs
6. RPM is Red Hat.  Red Hat is bad or something.
7. RPM is for people who don't build from source.

And my answers:

1. If you --force the installation of something (this includes
--nodeps), you'd better know what you're doing because chances are
what you're installing won't work.  If you don't have the
libraries or packages to resolve dependencies, or if RPM is
complaining you're going to overwrite something that's needed,
then RPM knows better than you.  Get and upgrade those packages
too.

You should never need to install a system with --force or --nodeps
(or most of the --ignore flags), unless you *REALLY* know what's
going on.  IMHO the default 'rpm' tool shouldn't support them, and
a secondary 'dangerousrpm' app should be used.

2. RPM will only do what you tell it to.  See #1 about 'breaking
your system'.  RPM's system breaking usually only occurs when
-Upgrading or -Freshening an RPM and it plays with your
configuration files.

3. Packages are about trust.  That's why they can be PGP signed.  
If you trust Red Hat to provide you with good packages, then you
should feel that -ivh'ing a Red Hat RPM is like having built it
and installed it yourself.  RPM is for people who don't have the
time/energy/desire/CPU power to build every last package they own.

4. rpm -ivh *.rpm will install all the rpm's in a directory,
resolving interdependancies between packages automatically.

5. This used to be true.  rpm -U'ing a set of rpm's in a directory
used to install the ones that were not install before.  RPM 3.0
provides a -Freshen which will only update existing RPM's.

6. Every last line of source for RPM is LGPL'd.  Other
distributions (such as SuSE) have benefitted from this fact.  If
you think that a company that is proving you can make money and
give out source is bad, so be it.

7. RPM's are built from source.  You should be able to rpm
--rebuild any .src.rpm onto your system and use your compiler and
preferences.  You must of course trust (see #3) that the packager
has put together their sources properly.

Having said all that, I believe RPM needs two things added to it:

Pre-install and post-install scripts:

These install scripts would come in three flavours, "OPTIONAL",
"RECOMMENDED", and "REQUIRED".  The scripts would be able to store
their settings in the RPM database so that -U'ing an RPM could be
done automatically.

The scripts would work similar to the kernel configuration where
the information and logic is abstracted from the display system.
This would allow the installer to use GTK or ncurses, HTML or just
the straight console display to query information from the user.

The "pre-install" script would be run before the package was
installed.  For example, installing a set of CGI's via RPM would
need to know where your CGI's are kept.  This would be a REQUIRED
pre-install script.

The "post-install" script would be run after all the packages are
installed.  For example installing the MySQL RPM would prompt you
for a root password for your database.  This would be an OPTIONAL
pre-install script.

Package makers should always error on the side of automation over
security, but on the side of interactive over tossing files
randomly.  The RPM tool should default on the side of interactive
if stdin/stdout is a tty.

2. Packaged RPM's

A "packaged RPM" would be 1 RPM file which contained sub-RPM
files.  For example a "GNOME-2.0.i386.rpm" which was 40 megs and
contained a complete installation.  Or, a
"WordPerfect-8.0.i386.rpm" which would contain "WordPerfectApp",
"WordPerfectFonts", and "WordPerfectAppleTalkPrinterDriver" RPM
within it.

Combining the two features, you would posess the ability (in the
case of WordPerfect, for example), to prompt the user for what
Printer Driver they wish to use.  The display abstraction of the
configuration language would allow KDE, GNOME, AfterStep, etc, to
all use their own widget sets, and possibly even lead to a
web-based installer.

----

What this means.

This means that 'GNOME' is not the right place to solve the
problem with an install wizard.  The "correct" place (IMHO) is in
the installer tools.

Cheers,

	JAmes