add your Scheme implementation to Debian GNU/Linux

I'd like to encourage people to add their Scheme implementations to
Debian GNU/Linux.

Debian is one of the most popular Linux distributions (and my personal
favorite).  For a Debian user, having a Scheme implementation in Debian
*greatly* lowers the barrier to trying out the implementation.

For example, a Debian user can install DrScheme over the Internet simply
by executing the command "apt-get install drscheme".  Also, the Debian
user will be notified in the future of new versions of the "drscheme"
package, and be given the option of upgrading.

And if you want to release an application program that uses a particular
Scheme interpreter or runtime library, you can specify that dependency
in the the application's Debian package, so that the dependencies are
automatically installed when the application is installed.

There are already a number of Scheme-related packages in Debian:

bigloo - A practical Scheme compiler
bigloo-devtools - Tools to help developping Bigloo programs
bigloo-doc - Documentation for the Bigloo scheme compiler
bigloo-examples - Examples for the Bigloo scheme compiler
bigloo-runtime-2.6b - Run-time libraries for Bigloo-generated programs
bigloo-runtime-2.6c - Run-time libraries for Bigloo-generated programs
bigloo-ude - Bigloo Unified Development Environment for Emacs
chicken - Simple Scheme-to-C compiler
drscheme - Scheme Programming Environment
elk - the Elk Scheme interpreter
escm - Embedded Scheme Processor
gauche - A Scheme implementation designed for script writing.
guile-1.6 - The GNU extension language and Scheme interpreter
guile-1.6-dev - Development files for Guile 1.6
guile-1.6-doc - Reference and tutorial documentation for Guile 1.6
guile-1.6-libs - Main Guile libraries
guile-1.6-slib - Guile SLIB support
guile-common - Common files for all guile versions
guile-db - Berkeley DB module for Guile
guile-library - Library of useful Guile modules
guile-pg - Guile bindings for the PostgreSQL client library
guile-www - Guile WWW module
guile1.4 - The GNU extension language and Scheme interpreter
guile1.4-doc - Reference and tutorial documentation for guile 1.4
guile1.4-slib - SLIB support for guile1.4 and libguile9
idsa-guile - Guile module for IDS/A
libautounit-guile - Guile Unit Testing framework
libbigloo2.6d - Run-time libraries for Bigloo-generated programs
libbigloo2.6e - Run-time libraries for Bigloo-generated programs
libelk0 - implementation of Scheme (the Extension Language Kit)
libguile-dev - Development headers and static library for libguile
libguile-ltdl-1 - Guile's patched version of libtool's libltdl
libguile9 - libraries for Guile1.4 (guile, guilereadline, and qthreads)
libguilegtk-1.2-0 - GTK+ 1.2 bindings for the Guile scheme interpreter
libguilegtk-1.2-dev - GTK+ 1.2 bindings for the Guile scheme
interpreter - development files
libgwrapguile-dev - Development package for libgwrapguile1
libgwrapguile1 - g-wrap: Tool for exporting C libraries into Scheme
interpreters
libqthreads-12 - QuickThreads library for Guile
libswig1.3.21-guile - Runtime support libraries for swig generated wrappers
mit-scheme - The MIT/GNU Scheme development environment
mzscheme - Rice University PLT Scheme Interpreter
oaklisp - An object-oriented dialect of Scheme.
quack-el - Enhanced Emacs support for Scheme programming
r5rs-doc - Revised(5) Report on the Algorithmic Language Scheme
rscheme - Threaded, persistent, OO, scheme interpreter and compiler
scm - A Scheme language interpreter.
scsh - A `scheme' interpreter designed for writing system programs
scsh-doc - Documentation for scsh, "The Scheme Shell"
skribe-doc - Documentation for the skribe documentation production system
slib - Portable Scheme library
stalin - An extremely aggressive Scheme compiler
stklos - An efficient Scheme System providing a powerful Object System
swig - Generate scripting interfaces to C/C++ code
swig1.3 - Generate scripting interfaces to C/C++ code
texmacs - WYSIWYG emacs-ish mathematical text editor, using tex fonts
wiliki - Yet another Wiki clone written in Scheme

Info on how to add a package to Debian is at:
http://www.debian.org/devel/

It's a nontrivial process, but it works pretty well.

You don't have to be the author of a piece of software in order to
maintain it's Debian packaging -- in fact, most Debian packages are
maintained by non-authors.

Neil

"Neil W. Van Dyke" <neil@neilvandyke.org> wrote in message news:<phd5zw7tt7.fsf@neilvandyke
.org>...
> I'd like to encourage people to add their Scheme implementations to
> Debian GNU/Linux.

ACK! Must ... fight ... the ... RANT ... of DEATH!!!!!

> It's a nontrivial process, but it works pretty well.

Grrrrr.....And it looks like we're going to have to re-license all of
the SRFIs in order to allow people to include them with their
implementations. And all because we don't want people *changing the
standards* (which will be technically legal after the re-licensing,
even if it is morally reprehensible). Lest you think we're insane,
Debian doesn't even distribute the RFCs anymore because the RFC
licenses are insufficiently 'free'.

Do you have any idea *how* we're going to even find Olin Shivers, much
less get a response out of him? And given his track record with
automatic weapons I shudder to think what might happen if he does
respond. Perhaps we should just send out the Scheme Underground attack
helicopters to selected Debian priesthood addresses right now and have
done with.

Oh yeah, there is no Scheme Underground.

Deep breath.

Bleah. I gave in to the rant anyway.

Move along now. Nothing to see here folks. Move along...

david rush
<srfi-editor mode='standard-disclaimer'/>

kumoyuki@gmail.com (David Rush) writes:

> "Neil W. Van Dyke" <neil@neilvandyke.org> wrote in message news:<phd5zw7tt
7.fsf@neilvandyke.org>... 
>
> ACK! Must ... fight ... the ... RANT ... of DEATH!!!!!
> 
>
> Grrrrr.....And it looks like we're going to have to re-license all of
> the SRFIs in order to allow people to include them with their
> implementations. And all because we don't want people *changing the
> standards* (which will be technically legal after the re-licensing,
> even if it is morally reprehensible).

This is guff. Is TCP under threat because GNU/Linux includes an
implementation? Of course not. There is nothing to stop people
including SRFI implementations in a Debian GNU/Linux based distro.

Note that the SRFI licence is similar to the apache licence and is
perfectly acceptable under the SRFI guidelines.

What is not possible is to include the SRFI documents in Debian
because of their determination to use only free documentation (and
their definition of free in this sense is very strict). But this is
not a big deal because the SRFIs are avaiable on the web.


btw... IMHO the SRFIs have been poorly managed by the Scheme
community. As a Scheme  implementor it would be nice to be able to use
the documentation in some way other than by pointing people at it. A
texinfo version would work for me... but since the SRFI editors have
chosen to be laisseiz faire about editing standards it's not possible
to convert the documents into documentation formats other than HTML
(and we all know the problems with that).


Nic

>>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

[...]

Nic> btw... IMHO the SRFIs have been poorly managed by the Scheme
Nic> community. As a Scheme implementor it would be nice to be
Nic> able to use the documentation in some way other than by
Nic> pointing people at it. A texinfo version would work for
Nic> me... but since the SRFI editors have chosen to be laisseiz
Nic> faire about editing standards it's not possible to convert
Nic> the documents into documentation formats other than HTML (and
Nic> we all know the problems with that).

could be nice to write a scheme util similar to http://www.dewn.com/rfc/ but
for srfi. In this way, the 'client' can be  free (GPL or similar) and the
down-load and conversion is done by end-user hands.

thanks,
Maurizio

--
Maurizio Boriani
GPG key: 0xCC0FBF8F
fingerprint => E429 A37C 5259 763C 9DEE  FC8B 5D61 C796 CC0F BF8F <= fingerp
rint

Maurizio Boriani <baux@member.snospam.org> writes:
 
>
> [...]
>
>     Nic> btw... IMHO the SRFIs have been poorly managed by the Scheme
>     Nic> community. As a Scheme implementor it would be nice to be
>     Nic> able to use the documentation in some way other than by
>     Nic> pointing people at it. A texinfo version would work for
>     Nic> me... but since the SRFI editors have chosen to be laisseiz
>     Nic> faire about editing standards it's not possible to convert
>     Nic> the documents into documentation formats other than HTML (and
>     Nic> we all know the problems with that).
>
> could be nice to write a scheme util similar to http://www.dewn.com/rfc/ b
ut
> for srfi. In this way, the 'client' can be  free (GPL or similar) and the
> down-load and conversion is done by end-user hands.

Yes.

But what we need first is an SRFI for web access from Scheme. And
before we have that we need an SRFI for accessing sockets from
Scheme. And that should probably be expressed as a module.

So much to do...


Nic

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> kumoyuki@gmail.com (David Rush) writes: 
>
> This is guff. Is TCP under threat because GNU/Linux includes an
> implementation? Of course not.

This is a straw-man. TCP has such a wider usage base that this
comparison is meaningless. There are, in fact, mistakes in some of the
most widely-used SRFIs that ought to be fixed (e.g. argument
orderings). I for one, don't trust the implementor community to hew to
the letter of the SRFI if they can just change the document they ship
with their system.

Not that I mind if an implementor does fix the API, I just don't want
any hint that the changed API is a SRFI implementation. I'd vastly
prefer that the changed API get fed back into the process to result in
a new SRFI.

> There is nothing to stop people
> including SRFI implementations in a Debian GNU/Linux based distro.

That is not what the Debian people have said to some Scheme
implementors (w/rt the reference implementations). So, sorry, you're
wrong. There is a specific class of implementations which are
excluded from a Debian release: the Reference Implementations.

> Note that the SRFI licence is similar to the apache licence and is
> perfectly acceptable under the SRFI guidelines.

Of *course* the SRFI license is acceptable under SRFI guidelines. It's
not acceptable under *Debian* guidelines. And the SRFI process uses
the same  license for both the code and the ref impls which is
(intentionally) similiar to the HTTP RFC license, not the Apache
license. We have been negotiating this for *months* (with a tip of the
hat to David Van Horn who has done the painful legwork).

> What is not possible is to include the SRFI documents in Debian
> because of their determination to use only free documentation (and
> their definition of free in this sense is very strict).

And they consequently view IETF RFCs as insufficiently free to include
them in their distro. Their attitude amounts to *intentionally* missing
the point of standards documents for religious reasons.

> But this is not a big deal because the SRFIs are avaiable on the
> web.

If you are a Scheme implementor who is very conscientious about
distributing complete documentation, it *does* matter. Do you think
we'd engage in this painful exercise if their wasn't demand from the
implementor community?

> btw... IMHO the SRFIs have been poorly managed by the Scheme
> community. As a Scheme  implementor it would be nice to be able to use
> the documentation in some way other than by pointing people at it.

Just to stay on topic with my Debian Rant, this situation is
*effectively* imposed by the Debian license restrictions. The only
authoritative copies of the SRFIs are going to be the ones maintained
on schemers.org, and the Scheme Community will not be able to change
that.

Yes, you'll be able to include some kind of document which purports to
describe the SRFI-specified interface with your implementation, but
your *users* should check to see that it doesn't differ from the
authoritative versionm on srfi.schemers.org before making any
assumptions about it. It's a mutability issue, documents purporting to
describe SRFIs are about to become mutable data, whereas they were
once constants.

Am I being alarmist? Perhaps, but I simply can'y understand the lunacy
which drives the Debian people's attitude to making *standards*
documents *mutable*. It seems absolutely idiotic to me that they
should disallow the distribution of the very documents (IETF RFCs)
which have made their project possible. And I refuse to regard their
behavior as rational. In this matter they can be most charitably
described as misguided children who have no understanding of the adult
world.

> texinfo version would work for me... but since the SRFI editors have
> chosen to be laisseiz faire about editing standards it's not possible
> to convert the documents into documentation formats other than HTML
> (and we all know the problems with that).

I have had problems with the HTML template ever since my first day on
the job, probably for many of the same reasons as you. I spent some
time working on an XML DTD, but ran afoul of the wide variety of
things which may be the topic of a SRFI. I am ready to present the
case for a different format to the editorial team (and maybe even
retro-fit it to existing SRFIs), but I'd need to see a farily detailed
description of it first.

david rush
--
Engineering is the art of making what you want from things you can get.
-- Jerry Avins (on comp.lang.scheme)

David Rush <kumoyuki@gmail.com> writes:

> Yes, you'll be able to include some kind of document which purports to
> describe the SRFI-specified interface with your implementation, but
> your *users* should check to see that it doesn't differ from the
> authoritative versionm on srfi.schemers.org before making any
> assumptions about it. It's a mutability issue, documents purporting to
> describe SRFIs are about to become mutable data, whereas they were
> once constants.

But surely this is a normal situation. Most webservers don't ship with
a copy of rfc2616. They do ship with a manual which describes the
operation of the server's http stack. Most webservers manage to
implement http without a problem.

I don't see why the situation with SRFIs is different.

Another analogy is Scheme itself. AFAIK most implementations don't
ship a copy of R5RS. But they still manage to implement it.


> Am I being alarmist? Perhaps, but I simply can'y understand the lunacy
> which drives the Debian people's attitude to making *standards*
> documents *mutable*.

I am not a Debian developer, but I'm a GNU developer. Freedom is
important to us. I can understand why the Debian developers are not
convinced that standards documents should not be different from all
other documentation.

I don't agree with the Debian developers on this occasion, but I do
understand where they are coming from. They simply value freedom above
all else.



> I have had problems with the HTML template ever since my first day on
> the job, probably for many of the same reasons as you. I spent some
> time working on an XML DTD, but ran afoul of the wide variety of
> things which may be the topic of a SRFI. I am ready to present the
> case for a different format to the editorial team (and maybe even
> retro-fit it to existing SRFIs), but I'd need to see a farily detailed
> description of it first.

Are you really saying that docbook could not express everything that
an SRFI needs to say? Or even Texinfo?



Nic Ferrier

kumoyuki@gmail.com (David Rush) writes:

> ACK! Must ... fight ... the ... RANT ... of DEATH!!!!!

Don't fight it; embrace it.  It's sometimes the best way to get your own
misconceptions straightened out.

> Lest you think we're insane, Debian doesn't even distribute the RFCs
> anymore because the RFC licenses are insufficiently 'free'.

This doesn't prove one way or the other as to whether or not you're
insane, but Debian does distribute non-free software and documentation,
but puts it in a separate section.  If you want to be able to work under
the assumption that you can create derivative works from anything on
your disk, you exclude this section.  If you're willing to be a bit more
careful, you don't exclude that section and can do this:

blewis@softdev:~$ apt-cache show doc-rfc-std
Package: doc-rfc-std
Priority: optional
Section: non-free/doc
Installed-Size: 5312
Maintainer: Kai Henningsen <kai@debian.org>
Architecture: all
Source: doc-rfc
Version: 20030621-1
Replaces: doc-rfc-fyi-bcp (<< 20030621-1), doc-rfc-experimental (<< 20030621
-1), doc-rfc-std-proposed (<< 20030621-1), doc-rfc-misc (<< 20030621-1), doc
-rfc-old-std (<< 20030621-1), doc-rfc-0001-0999 (<< 20030621-1), doc-rfc-100
0-1999 (<< 20030621-1), doc
-rfc-2000-2999 (<< 20030621-1), doc-rfc-3000-3999 (<< 20030621-1), doc-rfc (
<< 20030621-1)
Filename: pool/non-free/d/doc-rfc/doc-rfc-std_20030621-1_all.deb
Size: 4822652
MD5sum: ce6598f1c82f9610bbe9ea22ae631c84
Description: Standard RFCs
The following categories are included:

David Rush <kumoyuki@gmail.com> writes:
 
>
> Hah! What planet do you program Scheme on? Most implementations *do
> not* implement R5RS in various ways. And they ship a document
> detailing the differences.

Yes. And mostly they're just about usable  /8->

I still don't see your argument. They generally don't provide R5RS but
they do (even if not completely) implement it.


> As it is to me. The Debian policy limits the freedom of communities to
> produce standards which may be relevant to software that ships on
> Debian. Do you get it yet?

I get that you are cross about this. But free software developers hear
arguments like yours from all sorts of people. The Debian developers
are just being consistent. To the nth degree and in a futile way, I
agree. But that is their perogative.

And I think it's an interesting question to get standards people to
start thinking about : what does it mean to have a standard in a free
software world.


As Bruce Lewis has pointed out, it's easy to include SRFIs in Debian
because you can put them in non-free. Non-free is not hidden from the
user on install, selection of non-free is prompted by the installer so
it's not a ghetto.


> By those standards by which I could consider a texinfo solution, HTML
> is also a perfectly adequate solution. I don't know enough about
> DocBook (other than to observe that everybody thinks it's the ultimate
> answer to documentation problems) to answer the issue. What *is* your
> problem with the HTML, then? Perhaps we don't have similiar concerns
> after all...

Ok. I'll mail you privately about this... but for the record my
problem is the lack of markup reduces the chance for reuse of the
original documentation. I would like to ship GNU Info documentation
with my scheme impl. I would like to import SRFI documentation into
the info but I can't because there is no editorial documentation
standard (because SRFIs use HTML which makes for a free for all of
markup).


Nic

I am a debian developer, but I'm only giving my view on this one. If
you've got other debian developers telling you other things, point me at
any public statements and I'll discuss with them. I'm pretty sure David
Rush *is* ranting groundlessly, though.

Talk about "priesthood" is insane among a group where almost all
proceedings are public.  Call us wrong if you want, but the priesthoods
are certain other "black box" operations. For example, where's the
srfi-editors list archive?  (For that matter, where's schemers.org
tonight?)

kumoyuki@gmail.com (David Rush) wrote:
> Grrrrr.....And it looks like we're going to have to re-license all of
> the SRFIs in order to allow people to include them with their
> implementations. And all because we don't want people *changing the
> standards* [...]

If you don't want people editing it and passing off as the approved
version, you should try digital signatures or something like
that. Otherwise, the black hats will ignore copyright law and change
them anyway, while these silly rules hurt friends who respect the
SRFI project's wishes, whether those friends are trying to create a
free software operating system or an improved SRFI outside the SRFI
process. Why hurt friends?

For the SRFI code, I'm pretty convinced by Michael Sperber's
reasoning about why it is free (January on schematics-development at
schematics.sf.net).  No-one has got off their backside to re-present
this to debian-legal, myself included. It doesn't seem that pressing,
as none of debian-legal seem convinced the other way enough to file bug
reports against scheme implementations AFAIK. I'll defer this work until
it has to be done.

> Lest you think we're insane,
> Debian doesn't even distribute the RFCs anymore because the RFC
> licenses are insufficiently 'free'.

This claim seems incorrect to me. Debian distributes them on its archive
network, but they can't be included in the operating system distribution.
I'll write a bit more in another reply on this topic.

--
MJR/slef  My Opinion Only: maybe not of any group I know.