First of all, thanks for doing this work. I encourage you to save your 
strength and not give up - it seems that now Squeak's problems are with 
technical culture and assumptions of common Debian developers, not with 
principles or licenses. These problems will probably disappear  once 
they get to know us sufficiently.


I would simply say that Debian developers relevant to serious packaging 
work on Squeak would be Smalltalkers, and all Smalltalkers can manage an 
image. Most Smalltalkers also consider an image a reasonable basis for 
maintaining code and patching it, even if said code is sometimes 
transferred as mcz or st files.


Basic packaging tasks (testing on another platform, setting paths and so 
forth) probably already doable by non-Smalltalkers, despite using images 
(building VM from C, parameters to VM).


Daniel


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