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)