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/
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080522/d0e4d2ce/attachment.htm