Re: Install program

[Jim Pick <jim jimpick com>]

Eirik Mikkelsen <eirikmik@orakel.ntnu.no> writes:

> I'm quite new to this list, so please forgive me if this issue has
> been brought up before. 
> 
> Has there been any discussion about an installation program for Gnome?
> Something like installshield on the Windows platform. 
> 
> The program would recognize different packaging formats (rpm, dpg, tgz
> etc). It is invoked from the gmc. In the case of rpm/dpg it acts as a
> frontend to the rpm/dpg-programs. In the case of .tar.gz/.tgz it looks
> for a file (eg .gnomeinstall) which tells it what needs to be done to
> the package. It could automagically do configure/make/make install in
> the case of source-packages (after parsing the scripts and showing the
> user/admin what is about to be done?), and install the programs for
> the current user only or for everyone according to privileges.
> 
> Any comments and/or flames? ;)

I've looked at several of these (not all of them though).  Most of
them seem very trivial.  KDE has a trivial one called kpackage which
can do RPMs and DEBs.

Right now, I use the Debian dselect tool (with the dpkg-ftp-x install
method) on my Debian system, and it does an admirable job - very
little manual intervention is required.

I don't use my Red Hat system very often, but I tried autorpm out.
(What do other RH guys do?  Probably mostly use rpm from the shell, I
guess)

Personally, I think the state of the art is represented by the guys
working on the Debian "apt" program (formerly known as "deity") -
which is supposed to be a replacement for the dselect program used by
Debian (which is pretty good as well, once you understand it).  It is
still a work-in-progress.

They are designing it so that it will eventually be useable for RPMs
as well.  But it's initial role is to act as a dselect replacement for
Debian (and it is taking a lot longer than they initially projected),
so that is their top priority.  Since they are all Debian guys, I
think they could probably use some help on the RPM part.

There is a frontend and a backend component to the system.  The
backend fetches the packages, and installs them (plus upgrades,
downgrades, removes, etc.).  The backend now works to a certain extent
for Debian packages (although I'm not using it yet).  The frontend is
for the system administrator to tag packages for various operations.

There can be multiple frontends - currently there are two (I think).

The old Debian dselect program can function as a front end (as it
always has been).  Because dselect always supported multiple "install
methods", the apt developers were able to slip in their backend.

They are writing a new X-based front end as well.  They have chosen to
write that in C++ using their own custom widget set (Jason Gunthorpe
had some problems with the design of Gtk, probably 'cause he's a C++
guy, so he chose not to use it).  Some of it works, but I find it very
confusing, and I didn't really understand it.  I think it's too early
for me to judge what they are doing though.

I think their backend will be the standard one for Debian eventually.
Apparently, it's got very advanced dependency handling too (lots of
graph theory, thanks to Manoj Srivastava).  I haven't seen anything
for Red Hat that even attempts to do anything as advanced.  If it
could be adapted to handle RPMs as well (as originally planned), it
would be quite slick.

Since multiple frontends can be made, there is no reason not to do a
Gtk based front end.  The multiple front-end idea is a stroke of
genius, because people can now implement their competing ideas for
configuration user interfaces.  This is the most important part of any
next-generation free software interface, because this is where system
administrators will "shop" for packages, and choose how they are going
to configure/build their system.

Personally, in a year or so, I'd like to see something written in
elisp or guile that could function inside emacs in a text-only console
window, or that same code could run as a "mode" inside gmc (no
difference really).

Add to that a "selection-time configuration language", and I think
you'd have a very good packaging system interface.  As the elisp/guile
frontend would be very scriptable, could be adapted to upgrade
networks of machines at a time (perhaps integrated with a network
monitoring/admin package).

Perhaps I am dreaming - but I think it could be done in time.

Cheers,

 - Jim

PGP signature