Return to README CVS log

Up to [LON-CAPA] / loncom / build / system_dependencies

notes about the history, philosophy and strategy about LON-CAPA and
its system dependencies

LON-CAPA AND SYSTEM DEPENDENCIES

Contributed by Scott Harrison, sharrison@users.sourceforge.net, 2002.

SYNOPSIS
--------
This directory, system_dependencies, is concerned with testing requisite
subsystems of LON-CAPA.  Two such subsystems are MySQL (a database layer
needed for both library and access servers), and perl (meaning the total
collection of necessary perl modules).

The rest of this file explains the history and philosophy of LON-CAPA
subsystems.

HISTORY
-------
Earlier approaches toward these subsystems were based on an
install-and-forget assumption.  For example, a system administrator
need only install an auxiliary perl software package (in addition
to the RedHat packages) and then the subsystem was considered
to be "valid".

However, the install-and-forget assumption does not take into
account the many dependency and filesystem conflicts that are
produced over time by events such as:

* changes in the LON-CAPA code;
* changes in perl (version 5.005 becomes 5.6.0 which becomes 5.6.1, etc.);
* RedHat OS changes (from RH6.2 to RH7.2 to RH7.3);
* available RedHat software packages change
  (RH7 has many subpackages for perl);
* the number and versions of perl modules being used by LON-CAPA change
  (we are adding Image::Magick as well as beginning to add SSL and XSLT
   perl modules);
* the multiple versions of subsystems that we produce to be compatible
  with different combinations of the changes above;
* needing to custom-patch various perl modules (such as HTML::Parser);
  and
* needing to expand the MySQL metadata table (which we have been postponing
  for a long time...).

I have identified at least 10 more CPAN distributions that should eventually
be added to a running LON-CAPA server system.  But with all the criteria
above, there is too much friction associated with adjusting the CPAN
composition on the server.

The install-and-forget assumption also creates difficulties for making
LON-CAPA portable to other UNIX-like systems such as Solaris, BSD-Unix,
and Debian.  While RedHat is the "supported" GNU/Linux system of choice,
it is negligent to not at least try and run LON-CAPA on top of other operating
system versions and flavors.

I am a hardcore advocate of being able to install LON-CAPA anywhere,
on any server (except for software that crashes too much--like Mircrosoft).

THE WORKING PHILOSOPHY
----------------------
The new approach is to, in a sense, work with sub-subsystems.

Since there are difficulties with the diagnosis and treatment of "MySQL"
and "1000+ perl modules" as standalone subsystems, the approach is to
work with sub-subsystems which are small enough to have:

* well-defined characteristics of installation;
* well-defined characteristics of unique identification and version-typing
  on the operating system;
* well-defined characteristics of testing.

Thus, you will see a certain flux right now as we move away from
one big "systemperl" RPM, to 32 CPAN-distribution-based self-extracting
binaries.

Never again will we be overlapping the filesystem with conflicting RPMs
(systemperl has encroached upon RedHat RPMs).  Never again will we be
maintaining multiple systemperl RPMs for multiple systems.

Now, the handling of perl is simply a process of asking:

* Is a CPAN distribution present on a LON-CAPA server system?
* Is a CPAN distribution the correct version for the current LON-CAPA code
  system?
* Is a CPAN distribution working on a LON-CAPA server when tested?

And, also very important:

* How do I add or update a CPAN distribution on a LON-CAPA server?
  (Answer: Download a self-extracting binary and execute!
           Or install manually from www.cpan.org.  It's up to you!)

CPAN handling on LON-CAPA is getting better.

.
.
.

Next on the list is MySQL.