Reasons to start and to stop the GIG

Why Don't We Need An GNOME Installation Guide As Urgently As In The Years Before?

Formerly I argued that three aspects demand the existence of an autonomous GNOME Installation Guide:

  • Not only the companies should have the knowledge to build the whole GNOME environment.
  • Users (like me)  should be able to build their own GNOME system manually if their distributions (like SuSE) ignore the GNOME (more or less)
  • There must be offered a way through the jungle of the unsorted GNOME tarballs.

But now - nearly six years after starting the GNOME Installation Guide and since nearly three years - the situation has been changed fundamentally:

  1. The knowledge of building a whole GNOME has been distributed so far that the preversions of GNOME 2.0 could already been offered in combination with more or less automatically working compile-environments, for instance GARNOME or CVSGnome.
  2. All distributions are offering a good collection of GNOME applications which are mostly up to date.
  3. GNOME-2.0 has been published not only with a well prepared schedule but also with a well made dependency diagramm

Regarding these facts one can and must say that the GNOME Installation Guide is no more as important as before: He is of course important as a special part of the GNOME documentation and as step of the quality assurance process because (nearly) all things have practically tested before they have been described. But he is no more important as practically used guide for the normal users. And of course these changings are not regrettable because the facts underline that the general situation of the GNOME development process has been improved.

[Addition in 2008:] As reaction of this improvement we said at the end of 2004, that from now on we would update the GIG only once or twice in a year and that this would be enough to fullfill the new reduced task of the GIG. But in fact the GIG project has been closed at this time and until now updates have not become nescessary again.

Why Did We Need An Autonomous GNOME Installation Guide?

There are at least three aspects which evoke the necessity of a GNOME Installation Guide, one general political cause, one local political cause and one GNOME specific cause:

A general political cause

The GNOME software is developed by the community. But the prebuilt GNOME packages are distributed by companies like «ximian», «eazel» or even «SuSE». These companies naturally have to earn money (with building and distributing such packages). Therefore, if these companies are the only one who have a description how to build up a stable GNOME system the community would be depend on that companies in a worse manner than windowsuser on MS: These have to pay for that what the company has developed. But those have to buy that what they themselves have developed.

A local political cause

In Germany GNOME isn't as popular as KDE. One of the causes may be that the packages offered by distributors like SuSE generally are not as modern as possible. That may be caused by the fact that GNOME is heavily developed. But that also may be evoked by the special view of such distributors: GNOME seems to be the second choice.

A GNOME specific cause

You may think that GNOME itself should and will offer such a GNOME Installation Guide, either in form of an explicit prescription or indirectly by a special organisation of the file server. But if you try that way you will meet many difficulties:

Formerly there have been two branches of GNOME, the stable and the unstable:

These two branches have now been merged into one. And - like the kernel prorammers - the GNOME programmers mark stable release by even release numbers

In both directories there exist a directory «sources» in which you can find the directories for the library tarballs and the application tarballs. So your first strategy may be to compile all of these packages. But in which order? And really all? The answer is «no»:

  • Some tarballs which can be found in the stable branch demand the installation of other tarballs which are not in the stable branch but in the unstable branch. Therefore they seem to be stable although they aren't. For the moment this is valid for «gnome-db» and «gnumeric». If you want to have them (and you will want to have at least gnumeric) you must expand your stable version by some unstable components.
  • Some tarballs which can be found in the stable branch demand the installation of other tarballs which are neither in the stable branch nor in the unstable branch. For the moment this concerns «sawfish», the standard GNOME windowmanager which requires «librep»
  • Some tarballs like «g-print», «libPropList» or «gfloppy» seem to be obsolete, either because they seem to be replaced by other tarballs («g-print» by «gnome-print»); or because they seem to be no more demanded («libPropList») or because they are also part of another greater and nescessary tarball («gfloppy» in «gnome-utils»).
  • Some tarballs like «xchat» or «gnome-linuxconf» are offered in a version which is already out of date.

Inside the branch «stable» there is - just beside the source directory - another interesting directory «latest». So your second strategy may be to compile all packages being listed inside of this directory. But it is already degenerated into a collection of links containing more than one version for each package. How should this collection lead to result?

Inside of the branch «stable» there is - just beside the source directory - another most interesting directory named «releases». Inside of this directory you find a directory gnome-1.4, gnome-1.2 and gnome-fifth-toe-1.4. And these directories themselves contain collections of links into the source directories of the stable and the unstable branch. Therefore these link-collections seem to be good candidates for indirect GNOME Installation Guides. But:

  • Both directories contain links to versions which are already out of date.
  • Both directories doesn't contain all possible or wishable packages.
  • Both directories have forgotten to name some very interesting applications.
  • Both directories list applications which can't be compiled.

Conclusion (between 2000 and 2004)

Therefore we need a practically tested way through the jungel of GNOME software, what means: A GNOME Installation Guide, which doesn't want to offer the only one way but at least one of the many possible ways.

Of course this guide can't never be ready or complete, because GNOME is heavily developed. For solving that problem this guide formerly has monthly been updated. Therefore our a timeslot formerly has have the size of nearly four weeks.