Policy for Scheme implementations supporting SRFI 22
The Scheme programming language is notorious for its lack of
standardization. The SRFI process is trying to mitigate this
problem. Particularily, SRFI 22, "Running Scheme Scripts on
Unix", tries to standardize interpreter names for Scheme scripts.
This is relevant to Debian as this introduces a name conflict if
two implementations of Scheme both want to support SRFI 22, and
thus provide the same interpreter command.
This should be solved as usual by using the alternatives system. In a
talk between the package maintainers of Scheme implementations, a
policy document was formulated which expresses the ideas and
concerns of all parties involved. This policy draft can be found at
The essence of the document is that
a) The interpreters defined in SRFI 22 should be managed by
b) Implementations should Provides: the appropriate interpreter
c) Scripts should Depends: on the appropriate interpreter names
The problem with b) and c) is that there's no standard available
to portably install Scheme modules as Debian packages, which
somewhat lowers the usability of the virtual packages, as
libraries that are required for a script might not be available,
and no Depends: line will make it available. Still, this at least
allows to depend on SRFI 22 implementations.
One other concern was that this policy talks a lot, but says
little. It can be summarized easily, as seen in the enumeration
above. The proposition was to use something like this instead:
Please use update-alternatives to provide /usr/bin/scheme-r5rs,
/usr/bin/... if appropriate. Priorities should reflect the
relative maturity and completeness of the implementations,
typically ranging from 10 to 50. Packages should "Provides:
scheme-r5rs" etc. if the named functionality provided is
standards-complete, or nearly so.
This is of course much shorter, but lacks the examples and detail.
As for virtual packages, this policy would create:
I have not yet created the bug report against debian-policy, as
this discussion might conclude that the virtual packages should
not be created.
Any comments on the proposal, or the mentioned problems of the proposal?
Debian GNU/Linux Developer