[Fedora-packaging] Squeak and Etoys packages

Wed Jan 21 23:09:44 UTC 2009

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...