On Thu, 2008-05-22 at 13:01 +0530, K. K. Subramaniam wrote:
> On Thursday 22 May 2008 4:28:29 am Jecel Assumpcao Jr wrote:
> > Our sources are the .image files. It isn't what people are used to, but
> > that doesn't make it less true.
> From the tone of the email, it looks as if Debian maintainer is just trying to 
> understand images and figure out how to handle images in their current 
> version control process.  Text-based tools like texteditor, cmp, diff, patch 
> etc.used in version control will not work with images. A Squeak image is not 
> a 'source' but records the entire state of a virtual machine. In a way, it is 
> like firmware to configure wireless devices or codecs required to interpret 
> certain audio/video files. VM mimics a virtual device and image is 
> its 'firmware'.
I suggest avoiding the firmware analogy.  Firmware has been a big
problem on Debian and they are working on (have?) purging it from the
main distribution.  The problem with firmware is that it does not meet
the "you can understand it and change it if you want" criteria--that is,
it is very difficult to do so with firmware, and the natural form of
firmware for human manipulation, which is source code, is generally not
available (if it is, I don't think the firmware is problematic).
> 
> The issues are:
> 
> 1. How does one compare two images A and B are equal?
> 2. If A and B are not equal, how to extract the patch which produced B from A?
> 3. How does one compare two patch set to see if they are equal?
> 4. Given an image A and a series of patches P1..PN, can different people apply 
> them in a sequence to produce the 'same' image, B.
> 5. Is an image file specific to an architecture or not (answer: not)
> 
Granted that these might be important for some purposes--and were raised
in the original email from Debian, I'm not sure they are central to
meeting the Debian Free software guidelines.

Debian has a concept of architecture-independent files; that would apply
to images (but not the VM).

Since the problem seems to be with Etoys, and more generally images (but
what about the "base" image?) an analogy is to an application.  Often an
application is a binary.  If you want to manipulate or change it, you
need the source code.  However, with an image, once you have it you
usually already have alll you need to understand and manipulate it,
unless the image was created by importing stuff that started out in some
other form (e.g., vector graphics or a model for an avatar).  In cases
like this, for example an application in a high-level language, I think
the source and the binary packages on Debian are quite similar.  The
source package has the high-level code and some package management and
installation logic.  The generated binary package simply installs this
in the right places when an installation is requested.