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