Re: GNOME Install Wizard?

["Jesse D. Sightler" <jsight mindspring com>]

Ok, I agree with a lot of what you said, but still feel that a few
comments are in order.  :)
james-gnome@tainted.org wrote:
> The correct place for this is in the underlying packaging
> mechanism (be it APT or RPM), for discussions sake, I'll use RPM.

Question:  Have you ever used Debian and dselect?

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

I basically agree.  Unfortuntely, RPM (at least pre-3.0, as I still
haven't upgraded) tended to be stupid about not understanding the
difference between shared libraries and programs.  IOW, barring just
plain incompatible RPMs, rpm -Uvh ought to always fall-back to rpm -ivh
if the old shared library can't be removed for dependency reasons.  But,
I think of this more as an RPM bug than anything else, so your point is
completely valid.  :)

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

Um, cute, but NO!  :)  Should we also have a "dangerous rm" command?  Or
hows about a "dangerous" fdisk command?  :)  If the user is intelligent
enough to be poking around at the command-line level, he had better read
the docs.  Simply hiding the program is not apt to help anyone.
 
> 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.

Agreed, and this is why RPM ought to handle configs more intelligently. 
More on this later.  :)

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

Um, do you realize that what you've just described is *.deb in
combination with dselect?  I just installed a debian 2.1 system with
Gnome the other week, and I must say that I was completely impressed. 
After it got finished installing the packages from CD, it queried each
package to see if they had been through their "post-install
configuration scripts" and interactively queried me to set them up. 
This is something that I have always missed in the RPM world, as it
pretty much leaves you on your own to do even the simplest (and most
necesary) customization of isntalled RPMs.  Then I wanted to install
Gnome, and literally all I did was tell it the ftp directory to get
everything from, select Gnome package, agree to the dependency
resolution, and watch it work.

AFAIK, debian already supports these pre-install and post-install
scripts, and will even let you postpone the post-install indefinately,
if desired.  Truly slick, IMO.  Unfortunately, most of the tools are
still basically text based.  But they are still impressive from a
technology standpoint.

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

If the distribution system were as slick as .deb, this wouldn't be
necessary.:)  Just give it the URL of package list, and select
"Gnome-1.0-task" and it automagically makes everything work. 

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

Agreed.  Display abstraction in the installer is a GoodThing (TM).  :)

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

Well, ORBit came from GNOME, and it is not a Gnome specific project. 
Why shouldn't this come about the same way?  HEheh, now that I think
about it, CORBA bindings might be cool.  :)

-- 
---------------
Jesse D. Sightler
http://www3.pair.com/jsight/