On Thu, 2008-05-22 at 13:27 +0200, 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.
> 
That's the reason I would like to chime in :) After 15 years of linux
experience I'm quite used to this sort of discussions.

>  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.
> 
Could be. What are exactly the reasons to bring etoys into debian? Do
need this to have etoys included somewhere else? Otherwise it would be
much less pain to have a separate debian mirror and to work towards the
requirements that are needed by debian to get it included at a later
time. Or just into ubuntu which should be slightly easier to accomplish.

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