My response would be to point out that an image is an executable that runs on top of a Squeak VM. Just like Java, where .java files get compiled into .class files and packaged into .jar files; just like any OS where .c files get compiled and packaged into ELF binaries; just like Python where .py files get compiled into .pyc files and packaged in zip files; Squeak compiles .st or .cs files and packages them into an image file.
It is *not* correct to say that a Squeak image cannot be compiled from source code. We do this all the time. It is correct that it is difficult to compile it *entirely* from source code but this is just as true for other executable files (the ELF headers are not generated from source code either!).
If the amount to which a system can be recreated from source code is a concern to the Debian people I think we can work this out (though maybe not immediately). But I'd be more than a little puzzled if they'd be making such artificial distinctions.
Cheers, - Andreas
Bert Freudenberg wrote:
Etoys was being considered to get into Debian. Now it may be rejected, because an image file is not "transparent enough" (see below). It was suggested to discuss this issue on the debian-devel list.
Do any of you have ideas how to respond? Are there perhaps other Debian packages that have a similar issue of accountability?
And how hard would it actually be to bootstrap a fresh Squeak image from sources nowadays?
- Bert -
Begin forwarded message:
From: Thomas Viehmann tv@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org, holger@layer-acht.org Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@debian.org
(OK, for technical reasons, this is not the REJECT, but there is little point in delaying this mail now that I have written it.)
Hi José, Bert, Holger,
this is, unfortunately, the REJECT of etoys. First of all, thanks Bert, Holger, José for the discussion of some of the concepts. However, I am afraid that there are some fundamental concerns that have not been eliminated (yet). As such I would like to invite you to start a discussion on the packaging of squeak session images on debian-devel@lists.debian.org. Feel free to forward this mail if you consider it useful as a starting point.
It seems to me that the method of distributing VM sessions in .image files as the preferred form of modification does not match too well with Debian practices of compiling packages from source and having easy access to the differences between various versions of a package.
So as far as I understand it it seems like a typical squeak image cannot be bootstrapped[1] from (textual) source and that the typical mode of operation is to modify some known image and distribute the result. As such, the preferred form of modification is indeed the image file.
This, in my opinion, raises at least the following questions that seem fundamental to me:
- How easy should it be to figure out what is in an image?
While the source code to any class seems to be available, the image is more than that. Does that matter? Should source of Debian packages be auditable and is etoys currently auditable easily enough?
- Does Debian (including the various teams that might have to take
a look at your packages) want to have easy access to the differences between upstream version, one Debian revision and another? Do squeak session images provide this in a way that is acceptable to Debian?
From the squeak wiki pages and your explanations it seems that what I would consider at least partial solutions exist, but it seems that either I am still lacking understanding of important concepts or that the etoys packaging (Debian and maybe also upstream) could possibly be made a bit more transparent. Of course, we might find out that my difficulties with the perspective of squeak images in Debian originate in misconceptions of Debian packaging and maintenance that I may have. Either way, I would appreciate if we could discuss this with the Debian development public at large and draw on their additional expertise.
Kind regards
Thomas
-- Thomas Viehmann, http://thomas.viehmann.net/