On Thu, 2008-05-22 at 15:17 +0200, Bert Freudenberg wrote:
> 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.
> 
Verification can be done by keeping one image and distribute MD5 sums
for image and source.

What channel of debian we are heading? main? Maybe that is a goal that
is not achievable at the moment. What about contrib? Or even non-free?

I have a package installed that is called flashplugin-nonfree. When you
install it it downloads an archive from adobe and installs a binary to
your system. You can hardly have less trust. 

Anywhere in between squeak has its place. 

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