Re: How come GNOME is hard to install.

[Gleef <dzol virtual-yellow com>]

On Sun, 14 Feb 1999, Yoni Elhanani wrote:
[lightly edited for readability]
> Hi.

Hello.


> Yesterday I Installed KDE on my friend's machine, (No flames, please)
> And it was the easiest thing I have ever installed in my life.

Why should we flame?


> I'd like to see gnome that easy to install, since it's target are
> users who have no idea how to compile and install.

It depends on what you mean by "it's target".  GNOME's target users
include people who have no idea how to compile and install, that
doesn't necessarily mean that we expect such people to be compiling
and/or installing GNOME.  I only expect four kinds of users to need
to touch tarballs or CVS code:
  * Developers
  * Power users
  * Systems administrators (installing GNOME at their network)
  * Distributors (eg. RedHat, Debian, etc.)

We certainly need to set up the GNOME source trees in such a way as to
minimize headaches for the above people.  On the other hand, someone
completely new to the Unix/Linux world will get their GNOME experience
the same way as they are likely to get anything else, through a
distribution.  This might be a complete Linux distribution (like
RedHat), or a third-party GNOME distribution (like Jeff Garzik
apparently has for Solaris), but the ease of installation is primarily
the job of the distributor, not the developer.

That being said, we do want to help make GNOME as easy as possible to
distribute, and I think we all agree that some work needs to be done.


> I'll try to suggest now how to solve that problem.
>
> I compare GNOME to KDE, not to say that KDE is better, or that I
> like it more, but to outline some of its (IMHO) strengthes for easy
> installation.  dont send me "if you like KDE so much then dont use
> GNOME".

 
> 1st trouble: bad/old RPMs
> -------------------------
> I'm not an expert on RPMs at all.
> but i think that RPMs should be made whenever possible,
> and that they're not so hard to do.
> So you need a spec file, big deal, somebody just programmed an
> entire UI, so a spec file (whatever it may be) should not be the
> thing that stops him from getting this UI to be installed on many
> computers.
> I know that its development, but try to get RPMs in time.

We have spec files and use them, they are in both the CVS tree, and
the tarball releases.  In theory, they should be staying up to date
with the releases, but sometimes they lag a bit.  The RPMs you find on
the the redhat directory of FTP site (and mirrors) are RHAD Labs'
distribution.  It is currently up to 0.99.7 (one minor release
behind), and from everything I hear they were a problem at one point,
but are improving in both quality and timeliness.

If you have problems with the RPMs, please post them here, so they can
be improved more readily.


> 2nd trouble: many libraries
> ---------------------------
> In order to start even the compilation of GNOME,
> one must have a huge amount of libraries,
> such as: GTK+, GLib, imlib, (requires libpng/gif/jpeg), ORBit, esound,
> libXml, others.
> In KDE all I had to compile is Qt. (No flames... please!)

In both GNOME and KDE, you need to compile, install or upgrade
whatever is either missing or out of date.  KDE focuses its
requirements on what they can count on being in most distributions,
but if you deviate from their expected distributions, you might have
real problems identifying what you need to install KDE.

In GNOME we do use many libraries which are not currently part of
major distributions (since they too are in development).  A GNOME
distribution generally would have a target machine in mind, and would
include all the libraries that should be needed.


> Another side of this problem, 
> is that you need the newest version of development libraries.
> That may  require you to recompile EVERYTHING so it will work with the
> newest lib.

Most Unixes and Unix-like systems, including Linux and *BSD, work just
fine with multiple versions of the libraries installed.  The only time
it gets tricky is if you want to DEVELOP for multiple libraries at once.


> I believe this is the biggest problem.
> I dont know how to solve either of these problems,
> but in order to have an easy installation we have to.

The "you need so many libraries" problem will fade as distributions
catch up to the state of the art.  The people on commercial Unixes
will probably be the furthest behind in this.

The "these are development libraries" problem is not a problem.  We
are using ld.so, not windows DLLs here.  There is a collateral problem
here, that is that Caldera refuses to distribute development
libraries, but that's their loss.


> 3rd trouble: scattered packages
> -------------------------------
> In KDE, one would install kdebase and get:
> kwm,kpanel,kdm,kconfig,kfm, and maybe other small utils.
> 
> However in GNOME, to get these functionalities, one must install:
> e (or any other gnome-compliat wm), gnome-core, gdm, control-center,
> mc.

First of all, I consider it a feature, not a problem, that we don't
stick a window manager in our base package.  Secondly, gdm needs to be
separate (and kdm should have been separate) because it needs special
installation attention, and might need to be upgraded quickly if there
is a security problem.  Likewise, having gnome-core and mc separate
allows me to upgrade them independently.

Gnome-core and control-center were split up to ease some development
problems, distributors might want to combine the two.  In general,
however, I much prefer to see independent programs packaged
separately, it makes system management easier.  There is nothing
stopping someone from making a GNOME distribution that has a window
manager, gnome-core, gdm, control-center and mc all bunched together.


> thats pretty much, aint it?

Why do you say that?  Both GNOME and KDE have five different programs
for the same five tasks.  We are just looking at a difference of
packaging philosophy here, not design philosophy.


> i'd suggest that we just put control-center and gmc into gnome-core when
> it is possible.

Gmc development is completely independent of gnome-core development.
Combining the two would cause problems both for gnome-core developers,
and the mc developers who aren't touching GNOME.

Control-center used to be in gnome-core.  Again, there's no reason
they can't be packaged together.  Distribution packages don't need to
match development trees.


> maybe even gdm (its not a big compilation, it shouldnt be too much).
> That would make the user able to install just one gnome package (except
> gnome-libs) in order to get a working gnome enviroment.

Gdm isn't needed for a working GNOME environment, and again, it should
be separate because it needs special treatment.


> The little applets, however, can be seperated into gnome-applets.
> since that (imho) they are not essential to gnome's enviroment.
> (maybe include only clock, mini-commander and pager applets since they
> are very useful)

Again, such rearrangements are completely possible, and up to the
distributor.


> 4th trouble: using gnome
> ------------------------
> This is the least trouble, and it can be solved easily.  but I think
> I should mention it.  When I installed KDE i had various scripts to
> help me run it.  such as kdm_on, usekde, startkde.  with gnome, it
> is very confusing to start gnome.  there was even a thread on "how
> to start it".  some suggested just gnome-session, some suggested 
> "wm &; gnome-session", some suggested just to run the programs:
> "mouse-properties &; sound-properties &;" , etc.
> that is very confusing.

I'll simplify it for you:
  * If you want session management, just run gnome-session.  Set up
    gnome-session so it will run everything else.  If that doesn't work,
    send in a bug report.

  * If you don't want session management, run the individual programs
    you want directly.


> i cannot even run gdm when i try to as root:
> "gdm_config_parse: Can't find the gdm user (gdm). Aborting!"
> I do believe that this is just misconfiguration or non-configuration
> problem, but newbies would be baffled by such a thing.  (luckily for
> me I like the "login:" console prompt).  such installation scripts
> would make it alot easier to install gnome.

I don't use gdm, so I'm not as familiar as I should be with its
workings.  Newbies shouldn't be playing with it, just like I wouldn't
recommend a newbie try a manual PAM or libc installation, they should
just use what the distribution gives them, they will be far happier
that way.


> Conclustion
> -----------
> If we want gnome to be as mainstream as KDE is now, we must make it
> more installable.  this is not a "compatition" againt KDE nor a
> "lets be like KDE" suggestions.  It's a "lets make installation
> easier" suggestion.  I assure you that if gnome was as easy to
> install as KDE, it would be as popular as KDE. (atleast when release
> version comes out).

I agree that installation needs to be easier for mainstream
acceptance, and GNOME could use some improved tools in that regard,
but we currently have people running GNOME on everything from AIX to
Solaris (any Ultrix or Xig users out there?), there is no way the
developers can make appropriate distributions for each configuration
of each platform.  That's why there are distributors.


> I know, you may say "developer's version", but if we want to get bug
> reports as quick as we can, we must allow many users to use it, thus
> shorting the beta phase, and improving the quality by eliminating
> bugs.

That is a good point, but given what I said, what how would you
broaden the installed base of beta testers?


> BTW,
> a RedHat installation (or any distribution installation that comes with
> gnome),
> is not a solution for all these problems.
> GNOME can be installed not only when linux is installed,
> but should be downloaded and installed anytime or anywhere.

I'm not sure I understand what you're trying to say here.

Best of Luck,
-Gleef