slib support and Scheme implementations

[Daniel Burrows <Daniel_Burrows@brown.edu>]

  The following is a proposal I first posted in response to a message
from "zhaoway".  I would like to reiterate it -- among other things, I'm
working on some software which uses slib, and I'd like to be able to
package it and have it work without sacrificing a chicken.  (or having
to import a hacked slib into my own source tree -- ugh!)

  A lot of the mail just explains the problem in boring detail for
people who don't know about it.  If you don't know about it you might
not care about this mail, but I've included it anyway :)

  The only mailing list I'm sending this to is -devel, as I don't see a
reason to involve policy right now (it makes more sense to document this
as a suggestion once we have agreement on a design and some working
code -- if ever)  I have Cced maintainers of all Scheme implementations,
as well as the slib guy.  (since I don't know who reads -devel and who
doesn't)
    (sorry if I've Cced anyone twice -- I'm just using packages.d.o)

  BACKGROUND:

  The Scheme standard defines a very minimal language, one which has
most of the basic primitives needed to write programs, but lacks a large
library of standard routines and some commonly useful features (such as
a standard way of testing for the existence of a file).

  The "slib" package is one start at addressing this problem.  It is a
large collection of routines which run on many Scheme interpreters; it
provides both useful utility routines (such as a way to sort lists, and
an implementation of queues), as well as some routines to paper over
differences in individual Scheme interpreters (for instance, a standard
name to test whether a file exists)

  slib is a useful collection of software, and it would be useful to
be able to simply write software that uses it.  Unfortunately, there are
some problems with the way this is currently handled, particularly if
Debian packages are to depend on slib.

  THE INSTALLATION PROBLEM:

  In an attempt to accelerate the loading of library files, slib stores
an internal catalog mapping logical module names (such as
'common-list-functions) to physical file locations (such as
"/usr/share/guile/1.4/slib/comlist")

  If this catalog were optional, we'd be fine, or at least not in such
bad shape; programs wouldn't run quickly without it, but they would at
least run.  However, that is *not* the case.

  If slib cannot open its library file, it attempts to create it in the
Scheme implementation's installation directory.  In the case of a UNIX
system where the Scheme implementation's data files are sensibly installed
into /usr/share or /usr/lib, this will result in "permission denied" --
generally causing the program to die.

  As an example, here is mzscheme blowing up after I've removed my
slibcat:
torrent:~> mzscheme
Welcome to MzScheme version 103, Copyright (c) 1995-2000 PLT (Matthew Flatt)
> (require-library "init.ss" "slibinit")

  So far, so good, but when I try to import an slib module:

> (require 'common-list-functions)
call-with-output-file: cannot open output file: "/usr/lib/plt/slibcat" (Permission denied; errno=13)

  The fix for this is simple: run the Scheme interpreter as root,
and load the slib module 'new-catalog (probably any will do, but this
forces it to be recompiled)  For instance, for mzscheme:

torrent:~> sudo mzscheme -mve "(begin (require-library \"init.ss\" \"slibinit\") (require 'new-catalog))"

  Currently we require every Debian user of slib to do this.  This is
ugly and will lead people to avoid slib.  (arguably this is stupidity on
slib upstream's part, but we can work around it)

  THE VERSION PROBLEM:

  I just note this since it was an issue recently.  It seems that slib's
catalog structure (or perhaps the contents of the catalog) is not
consistent across versions -- at least, I had to rebuild slibcat after
upgrading slib a few days ago, or all my code broke.  Therefore,
whatever solution we choose should probably rebuild the slib catalog(s)
after each slib upgrade.

  CURRENT PRACTICE:

  Most Scheme implementations just ignore slib.  However, guile (perhaps
because of gnucash) provides a package, guile1.4-slib, which has glue
scripts to automatically build guile's slibcat.  This is nice for guile,
but not helpful for other interpreters.
  I do not know whether Guile suffers from the "version problem", but
I'd imagine it does.

  THE PROPOSED SOLUTION:

  This solution is slightly inspired by install-emacsen and is fairly
simple.

  Two new directories will be created to handle slib:
/usr/lib/slib/install and /usr/lib/slib/remove.  Every Scheme implementation
that cares about slib should place a file with the same name as the package
in these directories.  Calling the "install" script should handle the
installation of (a new version of) slib (by creating or refreshing
catalogs); calling the "remove" script should delete the existing slib
catalog.
  Unlike the massive emacsen-common scripts, these are likely to be
three lines or so long.

  When an implementation is installed or removed, it calls
"/usr/lib/slib/slib-implementation-[install|remove] package" if this
file exists.  (this may not exactly be necessary -- we could call the
script directly based on some other criterion -- but it does give us a
useful level of indirection in case of the unexpected.  For instance,
this script could check whether slib is configured yet if that turns out
to be useful)

  When a new version of slib is installed, it calls each script in the
"install" directory; similarly, when slib is removed, it calls each
script in the "remove" directory.

  There is one thing that I'm not clear on: what about Scheme compilers?
If programs which are compiled with them get a dependency on a
particular package, we could perhaps put slib catalog compilation into
that package.

  I would like to see this in woody+1.  Please let me know if you have
any thoughts on it.  Probably it's not that hard to do if we can just
agree to do it.  (much less complex than, eg, the emacsen situations)

  I don't maintain any affected package, but I'm quite  willing to
submit patches if it's a problem for someone.

  Daniel

-- 
/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
|                    "Do you know why the prisoner in the                     |
|                     tower watches the flight of birds?"                     |
|                      -- Terry Pratchett, _Reaper_Man_                       |
\---- Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org