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...
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
