[squeak-dev] re: Squeak-4.5-All-in-One.zip

Ken G. Brown kbrown at mac.com
Mon Oct 13 21:17:35 UTC 2014


Having watched the recent discussions about troubles with the all-in-one release, I'd just like to make the observation that it might be time to forget the all-in-one. I personally don't like to have to download a bunch of extra large files if I just am interested in the release for a certain platform. And cluttering up the Mac .app folder with other stuff for other platforms just seems somehow really wrong. 

In my opinion it is pretty easy for a newbie to decide up front whether to download for Windows, Linux or Mac and have a nicely tailored install for that platform. 

My vote is to streamline the release process by dropping the all-in-one and just have separate downloads  for each platform. 

Ken G. Brown,
from my iPhone

> On Oct 13, 2014, at 08:19, Craig Latta <craig at netjam.org> wrote:
> 
> 
> Hi Eliot--
> 
>> Why uncompressed by itself?  If one uncompresses an archive
>> containing a foo.app with a bar sibling, that will surely produce
>> exactly the same bits in foo.app as uncompressing an archive that
>> contains only foo.app. The decompression program would be broken if
>> it creates different bits, right?  So...
>> 
>> If the archive is created in two steps, the first as you state
>> including only Squeak-4.5-All-in-One.app, using the finder, and then,
>> via the command line using zip -u to add the siblings how can that
>> not work?  It can't produce a different Squeak-4.5-All-in-One.app
>> without zip being hopelessly broken, which it isn't, right?
> 
>     Hey, I don't claim knowledge of why MacOS 10.9.5 behaves as it
> does, or that it should behave as it does (in fact, it seems rather
> stupid). I'm only relaying that, as far as I can tell:
> 
> -    If you sign the .app, then make a ZIP archive with the .app folder
>     and the scripts as siblings, then unarchive it, then MacOS 10.9.5
>     Gatekeeper rejects the signature (unless you have Gatekeeper
>     turned off).
> 
> -    If you use anything other than the Mac Finder GUI to make the
>     archive, or open it, then MacOS 10.9.5 Gatekeeper rejects the
>     signature (unless you have Gatekeeper turned off).
> 
>>> ...the release is now a ZIP archive that contains the two non-Mac
>>> launch scripts, along with another ZIP archive which contains the
>>> .app directory. This also means that non-Mac users will get the
>>> "__MAC" and ".DS_Store" debris after uncompressing, as well.
>> 
>> It doesn't have to be this way.  Use zip -u to add the siblings at a
>> later date.
> 
>     No; it's the Mac-Finder-GUI way of making the ZIP that adds the
> debris, apparently. At that later date, you've already lost, either by
> using the Mac Finder GUI to make the ZIP (and getting a good signature
> on open, and debris) or making the ZIP some other way (and getting a bad
> signature on open).
> 
>>> I still think all this is tolerable. However, I'll say again here
>>> that I strongly prefer having the .app directory be the root of our
>>> release artifact, a totally self-contained thing, and leaving it to
>>> users to set up launch shortcuts appropriate to their local system
>>> (given a directory structure that is obvious enough for them to
>>> realize how to do it).
>> 
>> Craig, you are a decent human being but...
> 
>     Yikes, Eliot. I don't think any of this has anything to do with
> what kind of human beings we are, and making that part of the discussion
> is hyperbolic to the point of histrionic. Please calm down?
> 
>> ...your attitude on this is so discourteous to users.
> 
>     Clearly we disagree about that. Specifically, the new users with
> whom I have worked see the expression of a clear boundary as to what can
> be moved around and renamed as a courtesy.
> 
>> Why *should* they have to unpack and decode the structure of a .app...
> 
>     Indeed, I would prefer that they not have to do that (I don't even
> like having to use ".app" in a directory name). I see a tradeoff between
> that and running into confusion later over where each piece of the
> release artifact is supposed to live, and what it can be named. I think
> the lesser evil here, and the greater courtesy, is for the release
> artifact to be a self-contained directory. I realize we disagree.
> 
>> ...especially when they might be Windows or Linux users only?
> 
>     ...and Mac users who prefer to use the command line. In the
> Appsterdam community here, I'd say there's an even split between Mac
> devs who prefer the command line and those who don't. They are all
> newcomers to Squeak.
> 
>     I use all the host platforms on which Squeak runs, regularly. I'm
> exploring how to make an all-in-one release artifact in the least
> contorted way. I don't think anything I've suggested is a slight against
> the users of any of the platforms/usage configurations.
> 
>     (What I *really* want, in addition to what we've done so far, is
> the option to install the system, launch it, stop it, etc., from a web
> browser. It would be something like the system launchers in Parallels
> and VMWare. But security constraints on all the platforms pretty much
> force us to have the user handle a downloaded ZIP file directly.)
> 
>> Why don't you see it as an obligation to provide a pleasant and
>> simple install step to that community rather than asking them to
>> perform a manual step?
> 
>     On the contrary, I do see an obligation to make the installation
> process as pleasant as it can be. Those users are already performing
> manual steps: downloading the ZIP file manually, unpacking it manually,
> and putting the contents somewhere in their filesystem manually
> (especially in the use case you seem to care about most, putting the
> contents in a directory which is already in their executables search
> path). Given that they are already performing these manual steps, I
> don't see what I propose as onerous.
> 
>     I'm curious as to why you didn't say anything sooner, after the
> all-in-one approach started years ago.
> 
>> I want to go on record therefore that I think providing the scripts
>> is important, especially for newbies, a group we surely want to
>> appeal to.
> 
>     Yes, we surely want to appeal to newbies. I think equating
> disagreeing with you on this with neglecting newbies is disingenuous.
> 
>     Anyway, yeesh. The decision was up to Chris and he made it (and he
> agrees with you); this issue is over, for 4.5 anyway. I don't see a lack
> of unanimity about it as a dire thing. Let's debate namespaces and
> modules instead. :)
> 
> 
>     thanks,
> 
> -C
> 
> --
> Craig Latta
> netjam.org
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
> 
> 


More information about the Squeak-dev mailing list