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 at beamnet.de>
>> Date: 21. Mai 2008 23:06:38 MESZ
>> To: "José L. Redrejo Rodríguez" <jredrejo at edu.juntaextremadura.net>
>> Cc: Bert Freudenberg <bert at freudenbergs.de>, ftpmaster at debian.org,  
>> holger at layer-acht.org
>> Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED
>> Reply-To: ftpmaster at 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 at 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
>>
>> 1. http://wiki.squeak.org/squeak/769
>> -- 
>> Thomas Viehmann, http://thomas.viehmann.net/
> 
> 
> 
> 
>