Re: Install program

[Jim Pick <jim jimpick com>]

Marc Ewing <marc@redhat.com> writes:

> Martin Baulig <martin@home-of-linux.org> writes:
> > Well, a graphically frontend to rpm would be nice to have. Something that
> > can list package descriptions/dependencies and also has support for
> > package building.
> 
> I'm working on "grpm" right now.  It does everything except building
> packages.  It handles multiple repositories of RPMs (local, FTP, HTTP,
> and is easy to extend to others), caches the info locally for fast
> access, and will tell you all about packages that are "new sice XX",
> new versions of stuff you have installed, etc.  Eventually it'll
> have a nice little drop target so you can drag stuff from gmc and
> grpm will handle all the dependency resultion (ie, locating other
> requires RPMs) and installation.
> 
> It should be ready for a first public release in a couple weeks.

Sounds interesting.

I've always felt Red Hat lacked a functional equivalent to dselect
(and now apt).

Based on the Debian experience, I'll warn you that it's not a trivial
exercise (although I'm sure you knew that already).

I'll try to explain my view of things, and what we should be working
towards.  If I make some inaccurate statements, please correct me.

Both dpkg and rpm share the same basic concept of packages.  This is a
very powerful concept, which fits the needs of electronic software
distribution perfectly (much better than the idea of "channels",
although it can be argued that they are the same thing).

The BIG difference between rpm and dpkg is basically a philosophical
one about interrupting the install process to prompt the sysadmin with
configuration questions.  With rpm, this is not allowed (I think).
With dpkg, this is allowed, and the whole system depends upon it.
Excessive prompting is frowned upon, however.

Prompting during the install process (as dpkg does) is a drag.  It
means that the phase where the packages are installed must be
supervised.  After you have selected the packages you want to
install/upgrade, you have to hang around.  When you are installing a
fresh Debian installation - if the user makes the very common mistake
of selecting too many packages to install at once - they will be
confronted with hundreds of questions (just like a long multiple
choice exam in school).

That's very aggravating to a new user, since they commonly won't know
the answers for all the questions.  And there is no easy way to
backtrack.  If don't know an answer, the best thing is to flub the
question (hit ^C or something) - and leave the package in an
uninstalled state so you can reinstall it later.  This has been
Debian's biggest PR problem - and explains why we always come out
behind Red Hat in reviews which focus on "ease of installation".

The philosophical decision of dpkg to allow prompting can be frowned
upon.  However, it is basically a "shortcut" which makes it possible
to install hundreds of packages at once, in widely varying
configurations, enabling dselect to do it's magic.  Debian has very
little configuration questioning built into the boot-disks.  Most
configuration questioning is handled by the individual packages.

Red Hat's rpm system, on the other hand, goes for the goal of having
an unattended install process, so prompting the sysadmin is a definite
no-no.

But some system configuration is always necessary.  Red Hat does this
by building most of the configuration questioning into the
installation process on the boot disks.  This works great for the
initial install.  Because this initial configuration stuff is
"centralized", and seperated from the individual packages, it does
limit the amount of variation that can be included.  That isn't a
serious drawback, as Red Hat is primarily targetted to be a consumer
product, positioned versus Microsoft Windows, which has basically the
exact same approach.

FWIW, Debian haven't opted for this approach (centralized
configuration), because the developers are very distributed, and just
don't have the coordination to be able to build a large install
program.  The Red Hat guys all work together, and get paid, so
building a large install program is easier.  That's why dpkg and rpm
have evolved differently, I think.

So for rpm, the initial installation is easier.  The flipside of this
is that it is harder to keep the system up-to-date and synchronized
over time (based on my limited experience), because there is no
equivalent of dselect.

A dselect equivalent for rpm is more problematic, because there is no
opportunity for configuration questioning during upgrades and new
package installation.  Upgrading a Red Hat system is best done by
upgrading the rpm's one-by-one, or in small batches, and configuring
them manually (perhaps using helper configuration programs) as you go.

So I think you'll probably end up with a "drpm" package that is
optimized for installing small batches of rpms - but it won't really
be the same thing as what dselect/apt does.

The future...

The way I see it, both dpkg and rpm have sub-optimal configuration
questioning schemes.  So there is an opportunity to improve this.  Not
only that, if they both adopt the same scheme, then that would remove
the big philosophical difference between them, and it would be trivial
to merge them or at least make them more compatible.

What could be improved?

1) No configuration questioning during the install phase (as Debian
   currently does) - this should all happen during the package
   selection phase, and the configuration options should be stored
   persistantly until the packages have been installed.

   Automated background upgrades would be possible.  I'm not too keen
   on them myself, except possibly for security updates while I am on
   vacation and for my clients.  On doing an unattended update,
   packages would just reuse the old configuration settings.  If new
   configuration questions need to be asked for the upgrade to
   proceed, the package could put itself "on hold", and wouldn't be
   upgraded until the sysadmin had run dselect/apt/drpm again manually
   and answered the question.

2) The configuration options should be shipped with the package, and
   not outside of them (ie. much of the configuration on the Red Hat
   install disks).  The packaging front end (ie. dselect, apt, grpm)
   should be able to ask configuration questions at package selection
   time (without having to download/install the entire package).

   This is a difficult problem in some cases, as the scripts that ask
   the configuration questions may need to examine the system in
   question, and may require helper programs.  It would be nice to be
   able to do the configuration locally for packages that are to be
   installed on a remote system.  It would also be nice if the scripts
   could be used with multiple styles of frontend (text console mode,
   gtk-based dialogs, automating scripting environments).

Separating the configuration scripts so they can be called at package
selection time shouldn't be too hard.  That just involves splitting
the Debian postinst scripts into front-end and back-end parts.  For
Red Hat, the frontend scripts would be a new feature.  And storing the
options persistently (between the time the frontend and the backend
script is run) shouldn't be hard either.

Developing a method of downloading "just the configuration scripts"
(not the whole .rpm or .deb) is a bit more work, but not really
difficult either.

Having frontend scripts that support multiple styles of user
interaction would be really easy if we had a little interpreted
"configuration language" to do this.  Perhaps it could be based on a
subset of Scheme (as I've suggested previously)?

This scheme involves several more levels of stuff than what either of
the current packaging systems use.  But if Red Hat and Debian could
cooperate and decide on a common way of doing things, we would be able
to bring the two packaging systems together.

Cheers,

 - Jim