[squeak-dev] Smalltalk images considered harmful

> 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 <[hidden email]>
> > Date: 21. Mai 2008 23:06:38 MESZ
> > To: "José L. Redrejo Rodríguez" <[hidden email]>
> > Cc: Bert Freudenberg <[hidden email]>, [hidden email],  [hidden email]
> > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED
> > Reply-To: [hidden email]
> >
> > (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 [hidden email]. 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/
>
>
>
>

> I have stages
>
> - squeak (the downloaded unmodified source)
> - bootstrap (patches like Delay, Semaphores, etc)
> - base (core packages)
> - app (deployable unit)
>
> Every stage is invoked with a startup script that patches the image
> and saves it to the next stage. That is exactly what a debian
> maintainer will do. Collecting some patch scripts (Smalltalk can
> patch itself :) ) and combine them with original source to a debian
> package.

> Regards.
> José L.
>
>
> 2008/5/22 Norbert Hartl <[hidden email]>:
>         Could you please announce when there is a discussion started
>         on debian-devel?
>        
>         thanks,
>        
>         Norbert
>         On Wed, 2008-05-21 at 23:34 +0200, 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 <[hidden email]>
>         > > Date: 21. Mai 2008 23:06:38 MESZ
>         > > To: "José L. Redrejo Rodríguez"
>         <[hidden email]>
>         > > Cc: Bert Freudenberg <[hidden email]>,
>         [hidden email],  [hidden email]
>         > > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost)
>         REJECTED
>         > > Reply-To: [hidden email]
>         > >
>         > > (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 [hidden email]. 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/
>         >
>         >
>         >
>         >
>        
>        
>        
>

> On Thursday 22 May 2008 4:13:40 pm Norbert Hartl wrote:
> > I have stages
> >
> > - squeak (the downloaded unmodified source)
> > - bootstrap (patches like Delay, Semaphores, etc)
> > - base (core packages)
> > - app (deployable unit)
> >
> > Every stage is invoked with a startup script that patches the image
> > and saves it to the next stage. That is exactly what a debian
> > maintainer will do. Collecting some patch scripts (Smalltalk can
> > patch itself :) ) and combine them with original source to a debian
> > package.
> Tracking dependencies and conflicts across patches, packages and VM is one of
> the strengths of Debian and a weakness in Squeak.

> If nobody else does it before I (as the Debian developer who has  
> prepared the etoys package and tried to include it in Debian) will  
> do it. But, I prefer to wait some time in order to know more  
> arguments from all of you. I guess this topic might become a flame  
> in debian-devel and I'd like to have as many arguments as possible.
>
>  Also, I'm a little burnout with this, after the license problems  
> seem to be fixed , these new problems make me feel I'm wasting my  
> time.
>
> Regards.
> José L.
>
>
> 2008/5/22 Norbert Hartl <[hidden email]>:
> Could you please announce when there is a discussion started
> on debian-devel?
>
> thanks,
>
> Norbert
> On Wed, 2008-05-21 at 23:34 +0200, 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 <[hidden email]>
> > > Date: 21. Mai 2008 23:06:38 MESZ
> > > To: "José L. Redrejo Rodríguez"  
> <[hidden email]>
> > > Cc: Bert Freudenberg <[hidden email]>,  
> [hidden email],  [hidden email]
> > > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED
> > > Reply-To: [hidden email]
> > >
> > > (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 [hidden email]. 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/
> >
> >
> >
> >
>
>
>
>

> If nobody else does it before I (as the Debian developer who has
> prepared the etoys package and tried to include it in Debian) will do
> it. But, I prefer to wait some time in order to know more arguments
> from all of you. I guess this topic might become a flame in
> debian-devel and I'd like to have as many arguments as possible.
>
>  Also, I'm a little burnout with this, after the license problems seem
> to be fixed , these new problems make me feel I'm wasting my time.
>
> Regards.
> José L.
>
>
> 2008/5/22 Norbert Hartl <[hidden email] <mailto:[hidden email]>>:
>
>     Could you please announce when there is a discussion started
>     on debian-devel?
>
>     thanks,
>
>     Norbert
>     On Wed, 2008-05-21 at 23:34 +0200, 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 <[hidden email] <mailto:[hidden email]>>
>     > > Date: 21. Mai 2008 23:06:38 MESZ
>     > > To: "José L. Redrejo Rodríguez"
>     <[hidden email]
>     <mailto:[hidden email]>>
>     > > Cc: Bert Freudenberg <[hidden email]
>     <mailto:[hidden email]>>, [hidden email]
>     <mailto:[hidden email]>,  [hidden email]
>     <mailto:[hidden email]>
>     > > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED
>     > > Reply-To: [hidden email] <mailto:[hidden email]>
>     > >
>     > > (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 [hidden email]
>     <mailto:[hidden email]>. 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/
>     >
>     >
>     >
>     >
>
>
>
> ------------------------------------------------------------------------
>
>
>  

> - Bert -
>
> On 22.05.2008, at 13:27, José Luis Redrejo wrote:
>
> > If nobody else does it before I (as the Debian developer who has  
> > prepared the etoys package and tried to include it in Debian) will  
> > do it. But, I prefer to wait some time in order to know more  
> > arguments from all of you. I guess this topic might become a flame  
> > in debian-devel and I'd like to have as many arguments as possible.
> >
> >  Also, I'm a little burnout with this, after the license problems  
> > seem to be fixed , these new problems make me feel I'm wasting my  
> > time.
> >
> > Regards.
> > José L.
> >
> >
> > 2008/5/22 Norbert Hartl <[hidden email]>:
> > Could you please announce when there is a discussion started
> > on debian-devel?
> >
> > thanks,
> >
> > Norbert
> > On Wed, 2008-05-21 at 23:34 +0200, 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 <[hidden email]>
> > > > Date: 21. Mai 2008 23:06:38 MESZ
> > > > To: "José L. Redrejo Rodríguez"  
> > <[hidden email]>
> > > > Cc: Bert Freudenberg <[hidden email]>,  
> > [hidden email],  [hidden email]
> > > > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED
> > > > Reply-To: [hidden email]
> > > >
> > > > (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 [hidden email]. 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/
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>

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

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

> On Thu, May 22, 2008 at 5:34 AM, K. K. Subramaniam <[hidden email]>
> wrote: ....
>
> > I see conformance Debian guidelines as a positive for the future of
> > Squeak. We may finally leave behind the annoying MNUs during file-ins.
> > Just imagine being able to replicate Alan Kay's famous demo image with a
> > simple "apt-get install squeak-demo" :-).
>
> Ah, now I'm intrigued, what is this famous demo image from Alan Kay?
> Could you elaborate?

> On Thursday 22 May 2008 5:46:58 pm Victor Rodriguez wrote:
>> On Thu, May 22, 2008 at 5:34 AM, K. K. Subramaniam  
>> <[hidden email]>
>> wrote: ....
>>
>>> I see conformance Debian guidelines as a positive for the future of
>>> Squeak. We may finally leave behind the annoying MNUs during file-
>>> ins.
>>> Just imagine being able to replicate Alan Kay's famous demo image  
>>> with a
>>> simple "apt-get install squeak-demo" :-).
>>
>> Ah, now I'm intrigued, what is this famous demo image from Alan Kay?
>> Could you elaborate?
> See
>   http://video.google.com/videoplay?docid=2409496407757723940
>
> at around 1h14m when Dan shows "PERFESSOR BILL EDWARDS" ensemble  
> demo that
> Alan put together in Squeak.