Yeah, what a bummer. Thank you so much, José, for starting it anyway.

I think the problem with Thomas of the Debian team is not that he does  
not understand what an image is (José and I explained in e-mail, and I  
also had a chat with him). But the huge monolithic image does not fit  
well with the regular package maintenance procedure. Given a new  
image, how can one be sure what's in it, and what changed? It's all  
based on trust, with little verification.

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