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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org, holger@layer-acht.org Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
My response would be to point out that an image is an executable that runs on top of a Squeak VM. Just like Java, where .java files get compiled into .class files and packaged into .jar files; just like any OS where .c files get compiled and packaged into ELF binaries; just like Python where .py files get compiled into .pyc files and packaged in zip files; Squeak compiles .st or .cs files and packages them into an image file.
It is *not* correct to say that a Squeak image cannot be compiled from source code. We do this all the time. It is correct that it is difficult to compile it *entirely* from source code but this is just as true for other executable files (the ELF headers are not generated from source code either!).
If the amount to which a system can be recreated from source code is a concern to the Debian people I think we can work this out (though maybe not immediately). But I'd be more than a little puzzled if they'd be making such artificial distinctions.
Cheers, - Andreas
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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org, holger@layer-acht.org Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
On Thursday 22 May 2008 3:22:33 am Andreas Raab wrote:
It is *not* correct to say that a Squeak image cannot be compiled from source code. We do this all the time. It is correct that it is difficult to compile it *entirely* from source code but this is just as true for other executable files (the ELF headers are not generated from source code either!)
The alarmist subject line seems to trigger defensive responses. Debian just seeks is a prototypical VM (with full sources) that takes a prototypical image from which all other VMs and images may be generated through patches and file-ins. This is no different from previous quests for a 'minimal' image from which other projects like Etoys, Croquet can be built. The prototypical image does not contain any machine-specific code and may be treated like, say a WAV file
I see conformance Debian guidelines as a positive for the future of Squeak. We may finally leave behind the annoying MNUs during file-ins. Just imagine being able to replicate Alan Kay's famous demo image with a simple "apt-get install squeak-demo" :-).
Subbu
On Thu, May 22, 2008 at 5:34 AM, K. K. Subramaniam subbukk@gmail.com wrote: ....
I see conformance Debian guidelines as a positive for the future of Squeak. We may finally leave behind the annoying MNUs during file-ins. Just imagine being able to replicate Alan Kay's famous demo image with a simple "apt-get install squeak-demo" :-).
Ah, now I'm intrigued, what is this famous demo image from Alan Kay? Could you elaborate?
Best Regards,
Victor Rodriguez.
Subbu
On Thursday 22 May 2008 5:46:58 pm Victor Rodriguez wrote:
On Thu, May 22, 2008 at 5:34 AM, K. K. Subramaniam subbukk@gmail.com wrote: ....
I see conformance Debian guidelines as a positive for the future of Squeak. We may finally leave behind the annoying MNUs during file-ins. Just imagine being able to replicate Alan Kay's famous demo image with a simple "apt-get install squeak-demo" :-).
Ah, now I'm intrigued, what is this famous demo image from Alan Kay? Could you elaborate?
See http://video.google.com/videoplay?docid=2409496407757723940
at around 1h14m when Dan shows "PERFESSOR BILL EDWARDS" ensemble demo that Alan put together in Squeak.
Also see http://www.vpri.org/pdf/NSF_prop_RN-2006-002.pdf and http://www.squeakland.org/pdf/etoys_n_learning.pdf
Subbu
On 23.05.2008, at 00:00, K. K. Subramaniam wrote:
On Thursday 22 May 2008 5:46:58 pm Victor Rodriguez wrote:
On Thu, May 22, 2008 at 5:34 AM, K. K. Subramaniam subbukk@gmail.com wrote: ....
I see conformance Debian guidelines as a positive for the future of Squeak. We may finally leave behind the annoying MNUs during file- ins. Just imagine being able to replicate Alan Kay's famous demo image with a simple "apt-get install squeak-demo" :-).
Ah, now I'm intrigued, what is this famous demo image from Alan Kay? Could you elaborate?
See http://video.google.com/videoplay?docid=2409496407757723940
at around 1h14m when Dan shows "PERFESSOR BILL EDWARDS" ensemble demo that Alan put together in Squeak.
Indeed - this is what Squeak actually was about. Having fun with interactive media - music, animation, etc. The "free Smalltalk" is just a byproduct of that (an admittedly useful one of course).
So here's to fun! Cheers! :)
- Bert -
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 -
How about the Squeak FUSE plugin, say its a filesystem in a file.
Keith
Hi Keith,
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?
Not sure if this is any use - but in Dolphin I take the basic image and I call it with a command line parameter that indicates a root package to load from the file system (so called .pac files) - the loader then starts loading the package and all its dependencies checking for any errors that occur (if they do it fails startup) - it then begines a deployment routine to generate a .exe
I am wondering if the Debian guys might go for a super slim image in sqeuak which they have "blessed" and then you have a loader that reads in .mcz files to build up the rest of the more complete system. As mcz files are just zips that people could extract and diff - this might overcome there nervousness about future versions being difficult to compare for changes. On load completion you save a "development" image which can be used over and over again (as we have now).
Again, not sure if this is what the trouble is - but it might work.
Tim
This is a variation of the "human readable files" argument. So once again I claim that no such thing exists other than printed listings (which then are not machine readable, at least not much in practice).
The image file is our source: the preferred form for editing programs. It is far nicer when coupled with the .sources and .changes files, of course, but we can get by without these. You do need the proper application for dealing with the image - the VM.
Now we can dump out the image as a huge XML file and we should have no problems reading that back in. We can also develop a more refined system like the Transporter tool in Self. But would the result be human readable? Only in the sense that it could be printed and a person could read it over the phone to some other person. Nobody would understand it (unless it was a trivial "3+4" image) nor want to make any changes to it in this format. So I would argue that this would not be a "source file" by any reasonable definition even if it did play nice with cvs and vi. And having pointed text editors to my share of .sources and .changes files from various Smalltalk I would argue that these aren't quite sources for Squeak either (though they are from GNU Smalltalk and Little Smalltalk).
Our sources are the .image files. It isn't what people are used to, but that doesn't make it less true.
-- Jecel
2008/5/22 Bert Freudenberg bert@freudenbergs.de:
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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org, holger@layer-acht.org Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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?
Of course its auditable, easy enough for one who know how to use squeak tools: browser, inspectors and debugger. For those who think that image (object memory state) is something which can be expressed by source code, they are totally losing the point.
- 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?
Compare the Debian installation CD with squeak image. They are both images. They contain both: source code and binaries. They contain non-trivial structural organization (directories/files, some in compessed form, links e.t.c ) , which can't be expressed in form of some source code. So, what is the point in looking at differences between two Debian vanilla CDs? The only thing which you can state is, that they equal or they not. Then, when you get deeper, you can say what packages image contains, what is their versions. But we have nearly same model for squeak.
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
-- Thomas Viehmann, http://thomas.viehmann.net/
On 21-May-08, at 2:34 PM, 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?
I think it's important to establish what level of transparency Debian is looking for. Apparently they want to be able to compare different versions of the package and see what has changed. In reviewing those changes, what would they be looking for? Objectionable content? Malware? Copyright violations? Material that carries a license incompatible with the GPL? Insecure code? Bugs? Spelling mistakes? Depending on what they want to know we might be able to provide a way to provide that information.
Also, Andreas is right - it's probably possible to distribute Etoys such that it can be "built" by filing "source code" into a base image of some kind. If the base image didn't include Etoys itself (as distinct from Squeak) that would provide the kind of transparency that Debian is used to, at least as far as Etoys is concerned. That would make the debian version be different from the upstream distribution, which would presumably still be based on images.
Or it could be done in reverse - Etoys would be distributed as an image, but would have a way of spitting out textual representations that could be fed into the debian process. That might mean more than just filing out Smalltalk code. It could also mean spitting out files that represent other types of media: images, sounds, hierarchies of Morphs, whatever is deemed important.
Colin
"Colin" == Colin Putney cputney@wiresong.ca writes:
Colin> Also, Andreas is right - it's probably possible to distribute Etoys Colin> such that it can be "built" by filing "source code" into a base image Colin> of some kind. If the base image didn't include Etoys itself (as Colin> distinct from Squeak) that would provide the kind of transparency that Colin> Debian is used to, at least as far as Etoys is concerned. That would Colin> make the debian version be different from the upstream distribution, Colin> which would presumably still be based on images.
Would they accept a KernelImage (http://www.comtalk.eu/Squeak/98) and the rest of it as filein's?
Of course, even then, it means someone on the squeak release team would have to tear down an image and build it back up before releasing the "official" squeak, or we'd have to live with the idea that Debian is distributing a slightly different image.
El 5/22/08 12:26 AM, "Randal L. Schwartz" merlyn@stonehenge.com escribió:
Of course, even then, it means someone on the squeak release team would have to tear down an image and build it back up before releasing the "official" squeak, or we'd have to live with the idea that Debian is distributing a slightly different image.
I remember you this is exact my point of view. We must go to kernel and grow from kernel (or Spoon). And I remember all I put as "tentative" 3.11 for all could view and discuss , see http://tech.groups.yahoo.com/group/squeak/message/127740 I such image, we don't have Etoys and could load from packages.
If Debian people still complain, the .mcz could be converted to "human readable" .st or .cs.
Edgar
I think that the distribution of Squeak on Debian should be this way:
1- VM. A suitable current stable version of the squeak vm should be part of the distro. This is source code in the "classical" way that it is converted to an executable file shipped with debian or downloaded from the debian repositories/mirrors. This is already happening.
2. An independent repository/location/url (squeak.org) should provide a standard location (a la debian repo) from several images (minimal, Damian's, FunSqueak, etc), with a sensible name format, that should be downloaded (at the debian user responsability) at the postinstall step of installing squeakvm. This maybe can show the user the list (with short and full descriptions) of the goal of each image and the user should be given the chance of download them. All of then if he so wants. This can be a little like the ruby gems, where you download and install the gem program from debian and download the particular gems from other sources. Or maybe like the old sun java installation using make-jpkg. Or maybe like the bcm43xx drivers instalation from pre 2.4.25 kernels, where you install one part (the driver) from debian repos and the other part (the firmware for the wireless card) from a public site unrelated to debian.
So, I don't think that should be good to try to do all the debian way, because (as ruby's gems, as Perl's CPAN, as TeX CTAN) there is no way that debian could maintain all the code is in the web.
What do you think?
2008/5/22 Miguel Enrique Cobá Martínez m.coba.m@gmail.com:
I think that the distribution of Squeak on Debian should be this way:
1- VM. A suitable current stable version of the squeak vm should be part of the distro. This is source code in the "classical" way that it is converted to an executable file shipped with debian or downloaded from the debian repositories/mirrors. This is already happening.
- An independent repository/location/url (squeak.org) should provide a
standard location (a la debian repo) from several images (minimal, Damian's, FunSqueak, etc), with a sensible name format, that should be downloaded (at the debian user responsability) at the postinstall step of installing squeakvm. This maybe can show the user the list (with short and full descriptions) of the goal of each image and the user should be given the chance of download them. All of then if he so wants. This can be a little like the ruby gems, where you download and install the gem program from debian and download the particular gems from other sources. Or maybe like the old sun java installation using make-jpkg. Or maybe like the bcm43xx drivers instalation from pre 2.4.25 kernels, where you install one part (the driver) from debian repos and the other part (the firmware for the wireless card) from a public site unrelated to debian.
So, I don't think that should be good to try to do all the debian way, because (as ruby's gems, as Perl's CPAN, as TeX CTAN) there is no way that debian could maintain all the code is in the web.
What do you think?
2. or simple note where to download squeak image(s).
we can even reserve a web page, say squeak.org/debian
As a long-time Debian and squeak user--though I haven't done much squeaking lately--I'd like to see the 2 get together. I have some late-night thoughts.
One possible analogy is with systems such as virus and spam scanners that get regular updates from "upstream" (that is, upstream from Debian), sometimes directly from upstream. The image, or possibly change sets might be seen as analogous.
By the way, Debian does actually package at lots of pieces from repositories, include those for Perl, Python, TeX, and R.
Another analogy is to packages that have significant amounts of non-verbal data: star charts, representations of the solar system, music, maps. And many package have at least some graphical material. The main concern with these I was aware of was that some were just too big.
Thomas's message (appended below) seems to raise several distinct concerns.
The first is auditability in the licensing sense. Debian needs to be sure that the license of everything is known, and that the licenses are compatible with DFSG (Debian Free Software guidelines), as well as being compatible with each other. At one level it seems to me this could be addressed by a license that says "everything in the image is under this license." At another level, software systems frequently turn out, on inspection, to have parts with licenses that are either unclear or unfree. By unclear I mean it's not clear what, if any license exists, and who claims ownership or copyright. Sometimes the system includes components with licenses that don't get along (BSD and GNU?). So I'm not sure if the blanket assertion is sufficient. So Debian might want to take a closer look at the parts.
At the level of detailed check, things are harder. One advantage of text is that you can start at the top and go to the bottom, and known you've examined it all. In an image, there's always the possibility that you'll miss something (e.g., a game shows a copyrighted image only after an obscure series of steps), or that parts (e.g., the Welcoming text, other help, or some components) really might have someone who could pop up and claim them.
In principle one could enumerate all the objects in an image; maybe that would provide some comfort. One can even imagine a tool the identifies all text and audio-video like objects and the context in which they occur.
I think it has always been pretty clear that stuff going into squeak was under a very permissive license, so that might allay some of the concerns.
A second concern behind the desire for "source" is that people be able to inspect, modify and adapt what they have. I think the focus on text may be a bit misplaced here; that is simply an easy way to realize that. I don't know that Debian policy, or the more fundamental documents like Debian's "social contract" require it. I believe it is explicitly acknowledged that the editability is the key concern. For example, a postscript file is text, but distributing only postscript is not considered OK: one needs to distribute the material that generated the postscript. Someone else brought up pdf's. I think in Debian the idea is that if you have binary package with pdf's, you can get the source package, and the source package will have the raw materials that made the pdf, and that one can modify to create your own pdf.
Generally, the squeak image is also the most natural form for modifying itself. In fact, the whole source vs binary package distinction clearly arose for compiled languages (though not all Debian packages consist of programs that get run through a compiler), and is an awkward fit for smalltalk.
I think there may be some difficulties getting non-smalltalkers to wrap their heads around this self-referential quality of an image. But the whole system was clearly designed to be inspectable and malleable, and so seems to me fundamentally consistent with the DFSG's concerns that people be able to understand and modify the software they use. (The self-referential quality is not unique: C compilers are written in C, and most higher level-languages systems consist significantly of code written in the higher-level language).
A final concern is with the differences between versions. First of all, I'm not sure where that's coming from: it doesn't seem as central to the core Debian principles. Of course, it does have practical significance. The last time I checked, most of the evolution of images consisted of taking in change sets, or change set like things, so that seems pretty auditable. I'm not exactly sure what the dominant tools for managing updates are now, so perhaps life is not so simple.
There are other considerations that I don't think were raised in the message from Thomas, but seem worth mentioning.
First, there seem to be a lot of kinds of images floating around, and being proposed: minimal, beginner, developer, web developer, MVC, Tweak, Morphic, ... Should they all be packaged? Just some or one? None, with the message "go and pick one"? (the last doesn't seem too friendly, but is one way around the concern with images).
Second, images alone are not a good way for existing users to get updates, for the simple reason that using a new one will mean tossing out everything you've done. (Yes, I know there are ways to move stuff between images, but keeping current with an update stream seems easier.) This is a bit different from the typical Debian package. If I get a new compiler, I generally don't lose my source code. Debian has gone to great pains to make it easy to keep your customizations when you update other packages (e.g., apache, spamassassin). The only analogous strategy I can see would be to have the squeak launcher script automatically export your changes to a new image, and that's got all kinds of problems.
Third, Debian divides software into a "main" section and "non-free" (or maybe other?). My understanding is that squeak is in main. Software can't go in main if it depends on stuff outside of main. This might be problematic if some kind of "get the image yourself" method is followed. However, this issue only affects what section of the archive the package is in.
Finally, I am not a Debian Developer or an expert on Debian policy. I am not even exactly awake! I know I've gone on a bit, but I hope it's some help.
It probably would be useful to take the to debian-devel soon.
Ross Boylan.
Yeah, I know: top-posting :)
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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org, holger@layer-acht.org Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
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?
I think there are two issues in his mail. One is the lack of understanding how squeak works. It'd be kind to spend some words to make a few issues clear. I would try to figure out if there are lisp distributions that bring an image with them.
The main concern they have (and a few mentioned in response to you) is to have a history of the package changes and they need to have a chance to tweak the package if there are problems.
One thing we already have: a distribution image with a number that precisely determines an image. Maybe there is some lack of description what is in it exactly. The shrinking initiatives will help this a lot.
To build the image from source isn't IMHO quite necessary. A debian maintainer never changes the source of the original package. The packages are just patched. I do this on my webserver deployment.
I have stages
- squeak (the downloaded unmodified source) - bootstrap (patches like Delay, Semaphores, etc) - base (core packages) - app (deployable unit)
Every stage is invoked with a startup script that patches the image and saves it to the next stage. That is exactly what a debian maintainer will do. Collecting some patch scripts (Smalltalk can patch itself :) ) and combine them with original source to a debian package.
We have an upstream which is kind of detailed. AFAIK the upstream version changes are changesets. So it would be possible to save every single version bump as changeset and in the debian changelog (which is needed to produce versioned package anyway).
In my opinion all we need is a script the does one version upgrade to an image from the commandline. I just don't know if there are updates of images like etoy that can be done by simply applying a changeset.
If it is necessary to produce text based diffs this can be produced on message level. If they need the source it should be possible to have script that applies the .changes to the .sources and then there are sources as well.
My 2 cents,
Norbert
- Bert -
Begin forwarded message:
From: Thomas Viehmann tv@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org, holger@layer-acht.org Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
On Thursday 22 May 2008 4:13:40 pm Norbert Hartl wrote:
I have stages
- squeak (the downloaded unmodified source)
- bootstrap (patches like Delay, Semaphores, etc)
- base (core packages)
- app (deployable unit)
Every stage is invoked with a startup script that patches the image and saves it to the next stage. That is exactly what a debian maintainer will do. Collecting some patch scripts (Smalltalk can patch itself :) ) and combine them with original source to a debian package.
Tracking dependencies and conflicts across patches, packages and VM is one of the strengths of Debian and a weakness in Squeak.
Subbu
On Thu, 2008-05-22 at 17:35 +0530, K. K. Subramaniam wrote:
On Thursday 22 May 2008 4:13:40 pm Norbert Hartl wrote:
I have stages
- squeak (the downloaded unmodified source)
- bootstrap (patches like Delay, Semaphores, etc)
- base (core packages)
- app (deployable unit)
Every stage is invoked with a startup script that patches the image and saves it to the next stage. That is exactly what a debian maintainer will do. Collecting some patch scripts (Smalltalk can patch itself :) ) and combine them with original source to a debian package.
Tracking dependencies and conflicts across patches, packages and VM is one of the strengths of Debian and a weakness in Squeak.
Can you elaborate on the "..across patches, ..." part? I do not know what you mean by that. Talking about dependencies it'd be better to compare debian archive format with Universe. Extending Universe with two or three features would make it as valuable as dpkg for debian users.
Even if squeak could cope well with all sorts of dependency and conflicts management it wouldn't change much. Debian is an operating system and they are looking for an operating-system-way to do all these things.
Norbert
On Thu, 2008-05-22 at 14:42 +0200, Norbert Hartl wrote:
Even if squeak could cope well with all sorts of dependency and conflicts management it wouldn't change much. Debian is an operating system and they are looking for an operating-system-way to do all these things.
Debian is a distribution that includes operating systems (primarily Linux, but at various times BSD and Hurd) and a lot of other software.
On Thu, 2008-05-22 at 11:03 -0700, Ross Boylan wrote:
On Thu, 2008-05-22 at 14:42 +0200, Norbert Hartl wrote:
Even if squeak could cope well with all sorts of dependency and conflicts management it wouldn't change much. Debian is an operating system and they are looking for an operating-system-way to do all these things.
Debian is a distribution that includes operating systems (primarily Linux, but at various times BSD and Hurd) and a lot of other software.
Of course, debian is a distribution system for software. But for me it is an operating system, too. The name is DebianLinux but you can savely omit the Linux and everybody knows what you mean :)
To be correct (I think you wanted to be) none of your examples is an operating system. Linux and Hurd are kernels and BSD is an operating system family.
Norbert
Norbert Hartl wrote:
On Thu, 2008-05-22 at 11:03 -0700, Ross Boylan wrote:
On Thu, 2008-05-22 at 14:42 +0200, Norbert Hartl wrote:
Even if squeak could cope well with all sorts of dependency and conflicts management it wouldn't change much. Debian is an operating system and they are looking for an operating-system-way to do all these things.
Debian is a distribution that includes operating systems (primarily Linux, but at various times BSD and Hurd) and a lot of other software.
Of course, debian is a distribution system for software. But for me it is an operating system, too. The name is DebianLinux but you can savely omit the Linux and everybody knows what you mean :)
To be correct (I think you wanted to be) none of your examples is an operating system. Linux and Hurd are kernels and BSD is an operating system family.
Do squeak run on Hurd ?
Karl
On May 23, 2008, at 4:05 AM, Karl Ramberg wrote:
Do squeak run on Hurd ?
I didn't trace back in the thread to get the context for this question, but addressing it at face value, the answer is (probably) yes and no. This is like asking whether Squeak runs on Mach, which has the same answer. Yes, because OS X uses a Mach microkernel. No, because OS X Squeak doesn't make any Mach calls directly; it interfaces with the BSD subsystem (plus other OS X APIs).
Cheers, Josh
Karl
I think a fruitful way to continue the discussion with Debian would be to try to take a step up from the mechanical issues raised in Thomas's original message to try to discover what the substantive concerns behind them are--e.g., licensing, the right to inspect and modify software, etc. It seems to me he has translated those into the modes that are typical for source/binary software, and it would better to get the substantive requirements from Debian and then for us to think about how those can be met in the context of squeak (and persuade Debian that way is appropriate).
The rest of this message is a response to the dialogue below, which is arguably wandering off topic to the nature of Debian. However, just as Debian needs to understand a bit about squeak to make the integration work, squeak needs to understand a bit about Debian. It seems to me that Norbert's characterization of Debian, or at least some possible readings of it, are a bit misleading.
On Fri, 2008-05-23 at 11:39 +0200, Norbert Hartl wrote:
On Thu, 2008-05-22 at 11:03 -0700, Ross Boylan wrote:
On Thu, 2008-05-22 at 14:42 +0200, Norbert Hartl wrote:
Even if squeak could cope well with all sorts of dependency and conflicts management it wouldn't change much. Debian is an operating system and they are looking for an operating-system-way to do all these things.
I'm not sure what you meant by "looking at things in an operating system way," but most of the effort in Debian goes into packaging applications. They definitely want it so that if you pull in package x you will get all the other packages, at the appropriate version levels, that x requires to function.
Debian is a distribution that includes operating systems (primarily Linux, but at various times BSD and Hurd) and a lot of other software.
Of course, debian is a distribution system for software.
"distribution system for software" sounds as if it refers to the servers you can pull packages from, whereas "distribution," which is the more typical phrasing I've seen, implies an integrated and manageable set of software. Debian is both.
But for me it is an operating system, too. The name is DebianLinux
I don't think I've seen Debian ever referred to as DebianLinux in Debian. Debian has made a big deal about its main distribution being "Debian Gnu/Linux", where the GNU is an explicit reference to the fact that there's a lot of other software on top of Linux, and that there is or could be GNU/Hurd, GNU/BSD, etc. Of course, not all the software is GNU software, but please let's not go there.
but you can savely omit the Linux and everybody knows what you mean :)
www.debian.org provides more. At the top: What is Debian? Debian is a free operating system (OS) for your computer. An operating system is the set of basic programs and utilities that make your computer run. Debian uses the Linux kernel (the core of an operating system), but most of the basic OS tools come from the GNU project; hence the name GNU/Linux.
Debian GNU/Linux provides more than a pure OS: it comes with over 18733 packages, precompiled software bundled up in a nice format for easy installation on your machine.
[Ross: so the first paragraph says Debian *is* an OS, while the second says Debian *includes* an OS. Go figure.]
To be correct (I think you wanted to be) none of your examples is an operating system. Linux and Hurd are kernels and BSD is an operating system family.
Norbert
True. I think the GNU/BSD was to be using just the kernel of BSD, but I could be wrong. At any rate, I think that particular project was abandonned.
Your definition of an operating system may be "bigger" than mine; I'd include some core but non-kernel software in it, but not most of what are considered applications.
Ross
I don't know if anybody has already said this, but I think we should just have our own repository for debian. It seems much simpler than all this mess. mabye have on for Fedora also?
On 5/23/08, Ross Boylan RossBoylan@stanfordalumni.org wrote:
I think a fruitful way to continue the discussion with Debian would be to try to take a step up from the mechanical issues raised in Thomas's original message to try to discover what the substantive concerns behind them are--e.g., licensing, the right to inspect and modify software, etc. It seems to me he has translated those into the modes that are typical for source/binary software, and it would better to get the substantive requirements from Debian and then for us to think about how those can be met in the context of squeak (and persuade Debian that way is appropriate).
The rest of this message is a response to the dialogue below, which is arguably wandering off topic to the nature of Debian. However, just as Debian needs to understand a bit about squeak to make the integration work, squeak needs to understand a bit about Debian. It seems to me that Norbert's characterization of Debian, or at least some possible readings of it, are a bit misleading.
On Fri, 2008-05-23 at 11:39 +0200, Norbert Hartl wrote:
On Thu, 2008-05-22 at 11:03 -0700, Ross Boylan wrote:
On Thu, 2008-05-22 at 14:42 +0200, Norbert Hartl wrote:
Even if squeak could cope well with all sorts of dependency and conflicts management it wouldn't change much. Debian is an operating system and they are looking for an operating-system-way to do all these things.
I'm not sure what you meant by "looking at things in an operating system way," but most of the effort in Debian goes into packaging applications. They definitely want it so that if you pull in package x you will get all the other packages, at the appropriate version levels, that x requires to function.
Debian is a distribution that includes operating systems (primarily Linux, but at various times BSD and Hurd) and a lot of other software.
Of course, debian is a distribution system for software.
"distribution system for software" sounds as if it refers to the servers you can pull packages from, whereas "distribution," which is the more typical phrasing I've seen, implies an integrated and manageable set of software. Debian is both.
But for me it is an operating system, too. The name is DebianLinux
I don't think I've seen Debian ever referred to as DebianLinux in Debian. Debian has made a big deal about its main distribution being "Debian Gnu/Linux", where the GNU is an explicit reference to the fact that there's a lot of other software on top of Linux, and that there is or could be GNU/Hurd, GNU/BSD, etc. Of course, not all the software is GNU software, but please let's not go there.
but you can savely omit the Linux and everybody knows what you mean :)
www.debian.org provides more. At the top: What is Debian? Debian is a free operating system (OS) for your computer. An operating system is the set of basic programs and utilities that make your computer run. Debian uses the Linux kernel (the core of an operating system), but most of the basic OS tools come from the GNU project; hence the name GNU/Linux.
Debian GNU/Linux provides more than a pure OS: it comes with over 18733 packages, precompiled software bundled up in a nice format for easy installation on your machine.
[Ross: so the first paragraph says Debian *is* an OS, while the second says Debian *includes* an OS. Go figure.]
To be correct (I think you wanted to be) none of your examples is an operating system. Linux and Hurd are kernels and BSD is an operating system family.
Norbert
True. I think the GNU/BSD was to be using just the kernel of BSD, but I could be wrong. At any rate, I think that particular project was abandonned.
Your definition of an operating system may be "bigger" than mine; I'd include some core but non-kernel software in it, but not most of what are considered applications.
Ross
On 26.05.2008, at 16:20, David Zmick wrote:
I don't know if anybody has already said this, but I think we should just have our own repository for debian.
That's missing the point (besides, apt repos for squeak do exist).
The point is that with the relicensing effort we finally have the chance to become an regular member of the wider open source and free software community. Inclusion in Debian, Fedora, etc. will certainly get us a much wider user base, because Squeak or Etoys would be listed alongside all the other development or learning environments. It's much easier to get into specialized distros like Edubuntu if the package is part of regular distros. Etc.
You could even write software that depends on an existing VM and image and hence could be a small nice utility that does not have to bundle its own image and VM (and once Squeak opens the door it could be easier for subsequent Squeak-based apps to get accepted).
Now I am neither a Debian nor Fedora maintainer, but I hoped that there are people who use these (and other) distros and care enough about Squeak to push it into the right channels.
- Bert -
I just want to report you that etoys has just been accepted in the non-free branch of Debian. The reason to put it in non-free (even if I (we) consider it's free) is that we want to give the chance to the Debian users to use it while the discussion on moving it to main continues. The next step is filling a bug against ftp.debian.org saying that etoys in non-free is an error, as it's a free package.
From my point of view, the main obstacle for Debian is the fact of not being able to bootstrap, rebuild or check the changes in the image using plain text files. Some of the things that have been said in this thread might head to implement a way to demonstrate that this is possible, I guess that it will be possible with future images, not with the current one. Obviously, all the help or participation from the Squeak community to achieve this goal is very welcome. Also, if some of you would like to help to maintain Squeak in Debian, please, tell it, so we can consider creating an alioth project in Debian to maintain this image and future squeak images in the distribution.
As Bert previously mentioned, Debian is not only for Debian users, but also a seed for other distributions like mepis, knoppix, linex, skolelinux, ubuntu, etc. that use its repositories and packages, so having Squeak in Debian is a warranty to make its spreading and use easier for these distributions users.
Regards. José L
On Thursday 22 May 2008 6:12:16 pm Norbert Hartl wrote:
On Thu, 2008-05-22 at 17:35 +0530, K. K. Subramaniam wrote:
Tracking dependencies and conflicts across patches, packages and VM is one of the strengths of Debian and a weakness in Squeak.
Can you elaborate on the "..across patches, ..." part? I do not know what you mean by that.
Across code updates. If a package requires a particular update level, Squeak does not pull in those dependencies automatically before installing it. Also, Squeak does not come with an tool to diff an image with another image (say a new upstream image).
Of course, it is all a small matter of programming ;-).
Subbu
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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org, holger@layer-acht.org Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
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@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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez" jredrejo@edu.juntaextremadura.net Cc: Bert Freudenberg bert@freudenbergs.de, ftpmaster@debian.org,
holger@layer-acht.org
Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
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@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@beamnet.de> > > Date: 21. Mai 2008 23:06:38 MESZ > > To: "José L. Redrejo Rodríguez" <jredrejo@edu.juntaextremadura.net> > > Cc: Bert Freudenberg <bert@freudenbergs.de>, ftpmaster@debian.org, holger@layer-acht.org > > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED > > Reply-To: ftpmaster@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@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/ > > > >
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@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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez"
jredrejo@edu.juntaextremadura.net
Cc: Bert Freudenberg bert@freudenbergs.de,
ftpmaster@debian.org, holger@layer-acht.org
Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
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@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@beamnet.de Date: 21. Mai 2008 23:06:38 MESZ To: "José L. Redrejo Rodríguez"
jredrejo@edu.juntaextremadura.net
Cc: Bert Freudenberg bert@freudenbergs.de,
ftpmaster@debian.org, holger@layer-acht.org
Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED Reply-To: ftpmaster@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@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
-- Thomas Viehmann, http://thomas.viehmann.net/
On Thursday 22 May 2008 6:47:28 pm Bert Freudenberg wrote:
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
Huge images are a problem for Squeak developers too in terms of increased I/O and network transfer times. Slim images benefits everyone. Strictly speaking, a developer's image is much larger than the *.image file since the image contains pointers into two other blobs - *.changes and *.sources. The last blob is about 17MB and doesn't change between different images, so it is huge win to factor it out. If we apply the same factoring approach to large collections (sound library? pool dictionaries?) then maintenance could become easier. Bulky stable image segments could be hived off into project files and then merged into a single image at "build" time or even at run time.
Has anyone analyzed space consumption and distribution patterns of object from a image file? What explains the near doubling of image size between 3.2 and 3.8?
Subbu
30+ posts on this topic with some suggestions of significant work to satisfy the Debian gate keepers. Is Debian inclusion really this important? Don't get me wrong, I think inclusion would be great, but this thread does make me wonder what benefits would really come of it.
- Stephen
2008/5/22 Stephen Pair stephen@pairhome.net:
30+ posts on this topic with some suggestions of significant work to satisfy the Debian gate keepers. Is Debian inclusion really this important? Don't get me wrong, I think inclusion would be great, but this thread does make me wonder what benefits would really come of it.
As a beginning it would be inmediatly included in Debian Edu, so next upgrade of this flavour of Debian would add etoys to several thousand of student desktops. Also, it would be included with the olpc packages in Debian. So, in the short time you would see Squeak in many more places than today. In the medium term, new Squeak images could be added to the Debian repositories, including some interactive books made in Spain to study maths. In the long term I don't know...
About the many things that have been read in this thread, I'd classify them in two types: a) Those that criticize or comment the way Squeak is done and point to use a different way of building the images b) Those that criticize or comment the Debian arguments.
I'm only interested in b) as, speaking of today, I'd like to include the etoys image in Debian, not any other image. There are two reasons for it: the main reason is that VPRI warranties the license of the etoys image, and that does not happen with other images (as far as I know). The other reason is that I'm more focused in the educative side of Squeak.
Don't misunderstand me: answers of type a) are really interesting, but do not help for today's purpose. Regards. José L.
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@hartl.name mailto:norbert@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@beamnet.de <mailto:tv@beamnet.de>> > > Date: 21. Mai 2008 23:06:38 MESZ > > To: "José L. Redrejo Rodríguez" <jredrejo@edu.juntaextremadura.net <mailto:jredrejo@edu.juntaextremadura.net>> > > Cc: Bert Freudenberg <bert@freudenbergs.de <mailto:bert@freudenbergs.de>>, ftpmaster@debian.org <mailto:ftpmaster@debian.org>, holger@layer-acht.org <mailto:holger@layer-acht.org> > > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED > > Reply-To: ftpmaster@debian.org <mailto:ftpmaster@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@lists.debian.org <mailto:debian-devel@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/ > > > >
On Wed, May 21, 2008 at 11:34:04PM +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?
I'm not sure about this, but many languages require a big binary translator in order to build the language:
GCC requires a binary download of GCC to build GCC Haskell does too
I'm not sure how Squeak is different.
Ha! This ought to be fun. :)
I'm at work now but I definitely have opinions about this, more later.
-C
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Colin Putney -
Craig Latta -
Daniel Vainsencher -
David Zmick -
Edgar J. De Cleene -
Igor Stasenko -
Jecel Assumpcao Jr -
Joshua Gargus -
José Luis Redrejo -
K. K. Subramaniam -
Karl Ramberg -
Keith Hodges -
Matthew Fulmer -
merlyn＠stonehenge.com -
Miguel Enrique Cobá Martínez -
Norbert Hartl -
Ross Boylan -
Stephen Pair -
Tim M -
Victor Rodriguez