[squeak-dev] Smalltalk images considered harmful

Norbert Hartl norbert at hartl.name
Thu May 22 10:43:40 UTC 2008


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?
> 
I think there are two issues in his mail. One is the lack of
understanding how squeak works. It'd be kind to spend some words
to make a few issues clear. I would try to figure out if there
are lisp distributions that bring an image with them.

The main concern they have (and a few mentioned in response to
you) is to have a history of the package changes and they need
to have a chance to tweak the package if there are problems.

One thing we already have: a distribution image with a number 
that precisely determines an image. Maybe there is some lack
of description what is in it exactly. The shrinking initiatives
will help this a lot.

To build the image from source isn't IMHO quite necessary. A debian
maintainer never changes the source of the original package. The 
packages are just patched. I do this on my webserver deployment.

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. 

We have an upstream which is kind of detailed. AFAIK the upstream
version changes are changesets. So it would be possible to save every
single version bump as changeset and in the debian changelog (which
is needed to produce versioned package anyway).

In my opinion all we need is a script the does one version upgrade
to an image from the commandline. I just don't know if there are 
updates of images like etoy that can be done by simply applying a
changeset.

If it is necessary to produce text based diffs this can be produced
on message level. If they need the source it should be possible to
have script that applies the .changes to the .sources and then there
are sources as well. 

My 2 cents,

Norbert

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




More information about the Squeak-dev mailing list