Reorganization of the Allegro CL Patch Directories on Uunet

A new directory structure has been developed for patches on the uunet
ftp site.  The new structure will be phased in starting immediately.
It should be complete before the end of the year.

The new structure should provide easier access for browsing for all
patches on each hardware architecture and the set of patches kept on
the ftp site will be more nearly complete.

New Directory Structure:

The new directory structure is currently on ftp.uu.net (192.48.96.9) at

   ~ftp/vendor/franz/patches/4.2-new
  
However, this location will change as described below.


The structure of this directory is simple:

  .../4.2-new/<arch>/<dist-tree>

where <arch> is currently one of hp, mips, rs6000, sparc-solaris1 and
sparc-solaris2, and <dist-tree> is a directory structure that exactly
corresponds to the Allegro CL 4.2 distribution.  Thus, for example,
patches that normally go into lib/update on your Solaris1 (SunOS4) tree
are located in the .../4.2-new/sparc-solaris1/lib/update/ directory.

The directories that are currently set up in 4.2-new for each
architecture are:

build/c:             GC and operating-system patches (.o files)
build/rs:            Runtime-system lisp patches (.o files)
lib/code:            Full replacements for systems or modules (.fasl files)
lib/update:          Allegro CL regular patch files (.fasl files)
lib/update-clim-2.0: Allegro CLIM 2.0 patches (.fasl files)
lib/update-composr:  Allegro Composer 2.0 patches (note the strange spelling)


Phase-in Process:

This change will be phased in through the following steps:

 1. Effective immediately, the 4.2-new directory will become the prescribed
    directory from which to get patches.  The 4.2 directory will remain, in
    case there are any programs that periodically search the directory and
    automatically download patches, and which might count on a certain
    directory structure.  The current 4.2 tree will remain frozen, and no
    new patches will be created in it.

 2. In about a month, we will rename the 4.2 directory as 4.2-old, and the
    4.2-new directory will become 4.2, and an announcement like this one will
    be mailed.  A link from 4.2-new to 4.2 will be maintained so that those
    who have changed their automatic programs to point to 4.2-new will
    continue to operate.

 3. About a month after the switch, the 4.2-old directory will probably be
    removed, and the 4.2-new link will be deleted.  All that will remain is
    the new 4.2 directory.

============================================

Background:

Currently, to access Allegro CL 4.2 patches via ftp, anyone can ftp to
ftp.uu.net (192.48.96.9) anonymously and cd to ~ftp/vendor/franz/patches/4.2
to get to the patch directory system.  This directory is divided into
acl and clim-2.0 subdirectories, which are further separated by architecture.
Patches can then be retrieved by GET and/or MGET commands.


Problems:

There were several problems with the current approach:

 - Not all patches can be represented by the current structure.  Currently,
   only patches that are to be placed into the lib/update or into the
   lib/update-clim-2.0 directories of your 4.2 distribution are represented.
   This does not allow for any patches that

    - are full .fasl files (such as hash.fasl), which would belong in
      the lib/code directory.

    - are .o files, which might either belong in the build/c or build/rs
      directories.

    - are Allegro Composer patches.  This is theoretically possible,
      but would require creation of an entire composer subtree.

 - The directory structure is hard to traverse.  Placing the decision about
   what architecture to choose (e.g. sparc, hp, etc) so deep into the
   directory structure was found to be a less useful partitioning, and
   makes the "distance" between the set of clim patches and the set of
   acl patches further than is necessary.

 - The target directories in the distribution are not obvious.  Unless a user
   is experienced at retrieving the patches, the DESCRIPTIONS file has to be
   retrieved and read before the target directory is known.  This precludes
   just reading the whole directory directly into the lib/update directory
   (unless it is already known where the patches belong).


All of these problems were considered in designing the new directory
structure.


Duane Rettig, Franz Inc.        1995 University Avenue, Suite 275
<Franz.COM at duane> (internet)      Berkeley, CA  94704
uunet!franz!duane (uucp)        Phone: (510) 548-3600; FAX: (510) 548-8253