Re: compilation failure workaround (RH 5.2 / 2.22.10)

From: Matthew D. Langston (langston@SLAC.stanford.edu)
Date: Tue Aug 10 1999 - 01:00:22 MEST


Hi Jeff,

Matt> The majority of users use their computers for many other things
Matt> besides running ROOT.  It would be an unreasonable burden on users
Matt> to force them to maintain a particular configuration just so that
Matt> they could run ROOT.  A software package should serve its users,
Matt> not vice versa.

Jeff> My view on this is that the ROOT team provides a service by
Jeff> providing the tarballs.  Your last comment I think is turned
Jeff> around, though ... I would prefer that the ROOT team assume a
Jeff> _STANDARD_ configuration when they provide the tarball, and HOPE
Jeff> that any upgrades a user has done on their own would be
Jeff> compatible.

But why should a user have to "hope" that their system's configuration
is compatible with ROOT in the first place?  The problem of creating
dynamically configurable software was solved many years ago by the GNU
project.  So, why should we still force users to maintain a particular
configuration just to run *one* software package.  Imagine the nightmare
that would ensue if all software packages required a particular
configuration (luckily, they don't).

The GNU model is that a software package dynamically adapts itself to
its environment.  This is a *much* easier task than requiring the
environment to adapt itself to the software package.

Adding this style of dynamic configuration to any software package is
quite simple with GNU Autoconf, Automake and Libtool.  In ROOT's case it
is utterly trivial, since the work was already done for a previous
version of ROOT.

Jeff> The situation now with the 2.2.10 RedHat "5.2" tarball is that a
Jeff> user MUST upgrade, the standard configuration for 5.2 WILL NOT
Jeff> WORK with ROOT.

You are absolutely right concerning the *binary distribution* of ROOT,
and this is exactly the problem with users depending on binary
distributions.  If instead ROOT were primarily distributed in source
form, then problems like the one you describe would be easy to fix.
Source code patches have tremendous advantages over binary
distributions:

  1) They are tiny.
  2) They are easily transmitted via e-mail.
  3) They are easily applied.
  4) They often times only require the re-compilation of a handful of
     files (as opposed to recompiling the whole of ROOT from the
     beginning), etc.
  5) They encourage the ROOT user community to help one another.

For example, the patch I sent you which fixes ROOT so that it builds
cleanly on RedHat Linux 5.2 Intel was only 775 bytes (compressed) and
took me only a few minutes to create.  I am happy to do this since it is
so simple and straightforward.  However, I would have been reluctant to
create a new binary distribution (4.4 Megabytes compressed) just to fix
a simple bug 3 line bug.

On the other hand, if ROOT's primary distribution model is binary
distributions (which is the current state of affairs), then users are
forced to either downgrade to an older version of ROOT, or upgrade
significant parts of their systems.  Either approach seems unreasonable
to me.

Jeff> So a user must upgrade, and this is the user serving the software
Jeff> package.

Exactly.  Dynamically configurable software distributed in source form
would fix this.

--
Matthew D. Langston
SLD, Stanford Linear Accelerator Center
langston@SLAC.Stanford.EDU



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:38 MET