5:09 p.m.
This is some background information about the Squeak and Etoys
packages. The Etoys package is an important part of the XO software
that we are trying to move into Fedora, and Etoys depends on Squeak.
I've just submitted for review (BZ481056) the first of three packages
that make up the Squeak and Etoys packages that I've been working on.
I'll submit the other two packages for review as soon as I finish this
note.
There has been some issues with these packages in the past, in part
licensing issues, in part because Squeak and Etoys are somewhat
different than anything else. The licensing issues have been resolved,
these packages are now under Fedora acceptable licenses. This email is
an attempt to address the other issues. This is very long, for which I
apologize. I've tried to be through, perhaps too much so. If I can
answer any questions, please ask.
I think it is useful for anyone reviewing the Squeak and Etoys RPM
packages to understand the high level organization of Squeak and Etoys.
It is possible that these packages may require some exceptions to the
Fedora Packaging Guidelines.
Squeak is an implementation of the Smalltalk-80 programming
environment. Like most Smalltalk implementations, Squeak is not just a
programming language, but also contains a set of software development
tools for editing, understanding, documenting, storing, and distributing
Smalltalk source code.
Squeak is implemented as a virtual machine/image pair. The Squeak
virtual machine is analogous to the Java virtual machine in that in both
cases they are native host programs which implement a virtual machine
specific to the language in question. One major difference between the
Squeak and Java virtual machines is that whereas the Java virtual
machine loads a set of ".class" files which were compiled from Java
source code stored separately in native 'text' files, the Squeak
virtual machine loads a single Image (a squeak virtual machine image)
which contains both the Squeak source code and the compiled (byte) code
that runs on the Squeak virtual machine. Squeak source is stored in,
edited in, distributed between, and compiled from and into an image file
running in a Squeak virtual machine. While it is possible to write
Squeak source code out to a native 'text' file, this is not commonly
done, and not the way that Squeak source code is typically edited or
distributed. The standard Squeak image contains all the source code for
itself, as well as all the tools one typically uses to create and edit
programs (editors, compilers, source code control, search and diff,
change distribution, ...) built into itself.
To get Squeak running, one needs both a Squeak Image (an image) and a
Squeak Virtual Machine (a vm). There is a 'standard' Squeak image
distributed by the Squeak project. It is the image that most people use
when running Squeak. Like all Squeak images it contains both the source
and compiled (bytecode) forms of the code in that image, and is the
expected way that one views and edits Smalltalk source code. There are
also a number of other Squeak images distributed for specialized
purposes. Etoys, for example, is a specialized Squeak image, as well as
some wrapper shell scripts to make starting it easy. The squeak-image
SRPM and RPM contain the "standard" Squeak image distributed by the
Squeak project. This image is installed under /usr/share/squeak, and
copied into directories owned by users user when the user starts Squeak
for the first time.
As stated above, the Squeak Virtual Machine (vm) is a native host
program which loads and interprets the bytecode within a Squeak Image.
The source for the vm consists of two main parts: the core interpreter,
and a large set of plugins which provide the core interpreter with
access to OS and environment specific features (like X, GStreamer, and
DBus on Linux). The core interpreter is written in a restricted form
of Smalltalk and maintained and distributed using the standard Squeak
software development tools. The plugins are written in C and
maintained and distributed as C source files typically are. The core
vm is compiled from the restricted Smalltalk into C, this compiled C
code for the core interpreter is combined with the plugins, and this
combination is what is distributed by the SqueakVM project, and is what
most people use as the source for building the Squeak vm. While it is
possible to create a Squeak VM from from the original restricted
Smalltalk stored in the Squeak image, it requires a working Squeak VM to
build a new Squeak VM from those original sources. The squeak-vm SRPM
contains the source distributed by the SqueakVM project, and that is
compiled into the squeak-vm RPM.
In preparing these packages, I have come up with several ways in which
these packages may fall outside the Fedora Packaging guidelines. The
first is that its possible that the "No inclusion of pre-built binaries
or libraries" rule applies to the Squeak images included in both the
squeak-image SRPM and RPM. My understanding of this Guidelines is that
it is meant to apply only to executable binaries which does not include
the Squeak image. Even if my understanding is not correct, the Squeak
image contains both to source and compiled forms of all of the code it
contains, and is the natural form in which Squeak/Smalltalk programmers
work with Squeak/Smalltalk code.
A second way in which these packages may fall outside the Fedora
Packaging guidelines is the fact that the source code for the core
interpreter part of the Squeak VM included in the squeak-vm SRPM is not
the original restricted Smalltalk source for this code, but is instead
the C source code created by compiling this original restricted
Smalltalk into C. While I could not find a guideline explicitly
forbidding this, it is possible that this could be outside the spirit of
the guidelines. To be clear the source included in the SRPM _is_ the
source distributed by the upsteam project, it's just not the original
restricted Smalltalk source for the core interpreter.
I've packaged it this way for several reasons. First, compiling from
the original restricted Smalltalk to C requires a working Squeak system
- a chicken and egg problem. Second, all existing Squeak distributions
compile the Squeak VM from the C source; if Fedora were to build it's
Squeak VM from the original restricted Smalltalk there is a small chance
that the built Squeak VM might be incompatible with other Squeak VMs.
I felt that, particularly for our first official release, we should
minimize this possibility. Finally, while the upstream SqueakVM project
does distribute the original restricted Smalltalk code for the core
interpreter (in a specialized Squeak image), and the needed tools and
instructions for building the C source from this Smalltalk source, they
are not yet rigorous enough in their release process to insure that the
C source produced from these images is exactly the same as the C source
they distribute. Because everyone uses the C source they distribute
(unless the explicitly want to build a non-standard VM), the needed
rigor has never been a priority. For these three reasons, I ask the
Packaging Committee to either decided that that this is not a violation
of the Guidelines, or grant an exception for this case.
A third way these packages may fall outside the guidelines is that the
Etoys package uses locales, but does not use find_lang. The Etoys
package puts it's local files in .../share/etoys/locale/..., but the
find_lang macro (as of F9) only looks in .../share/locale/.... I do
not know if this a a find_lang bug (find_lang should be looking in more
places) or a Etoys bug (etoys should not put it's locale files in it's
own special special place), and I have not taken the time to figure out
which. I'm sorry. If someone can tell me which is wrong, I'll see
about getting it fixed.
Of course these packages fall outside the guidelines in other ways
through my failure to understand or implement them correctly, but these
are the ways that I'm currently aware of. I've run rpmlint on the spec
files, the srpms and rpms. There were three warnings I felt I could not
or should not 'fix', they are documented in the BZ.
-gavin...