Packaging

Hi,

here's a bullet point list:
 - macOS Sierra needs a special vm compared w/ previous ones
 - macOS Sierra makes it hard to _just run_ downloaded bundles/All-in-ones
 - all-in-ones look ugly since Yosemite due to new requiremens for code signing.
 - we have some indirection in the shell scripts for the linux variant
 - we still have this strange LD_LIBRARY_PATH dance that apparently fails on
   newest Ubuntu (see recent mail)
 - occasionally, we have people from BSDen who also want to use Squeak.

So, I'd propose:
 - Ditch the AOIs.
 - Deliver macOS bundles as DMG, not as Zip, so as to force people to
   move the bundle, so that macOS Sierra is happy to run stuff.
In the long run:
 - Provide deb's and rpm's


Best regards
        -Tobias

-1 to ditching the All-In-One.  Freedom is being able to simply run a
binary out of a folder.  If one platform requires a special bundle,
then it'll require it in any case, but we should still also keep
generating the All-In-One for everybody else.



On Mon, Feb 27, 2017 at 6:00 AM, Tobias Pape <[hidden email]> wrote:

On 27.02.2017, at 21:01, Chris Muller <[hidden email]> wrote:

> -1 to ditching the All-In-One.  Freedom is being able to simply run a
> binary out of a folder.

Yes, then just download the one for your platform.

>  If one platform requires a special bundle,
> then it'll require it in any case, but we should still also keep
> generating the All-In-One for everybody else.
>

The AIO is getting cumbersome to build, codesign, and correctly use for
different platforms.
It is ludicrous that we point people to a .bat file on Windows, just because
macOS demands its top folder to be clean.
And the .app bundle is confusing on all but macOS.
And how do we introduce snaps[1] in the AIO.

Currently, we have this:



Let's just have this:




There's currently no actual advantage in having the AIO apart from supporting people like me who
are reluctant decision makers… ;)

Let's be frank, putting the AIO on an USB stick and running from that on different platform is really really seldom…


Best regards
        -Tobias

[1]: https://www.ubuntu.com/desktop/snappy

Am 27.02.2017 um 21:12 schrieb Tobias Pape:
> On 27.02.2017, at 21:01, Chris Muller <[hidden email]> wrote:
>
> There's currently no actual advantage in having the AIO apart from
> supporting people like me who
> are reluctant decision makers… ;)
>
> Let's be frank, putting the AIO on an USB stick and running from that on different platform is really really seldom…
And when I tried just this it didn't work out of the box on Linux
because I' didn't know what all to make executable.
Never tried on my wife's Mac. But I really carry Squeak from Windows to
Windows and would do the same to other OS.

So Yes to an AIO if it works everywhere from an USB stick or FLASH card
because then Squeak would be physically portable.
But No ATM it's too much hassle.

Cheers,

Herbert

On 02/27/2017 07:00 AM, Tobias Pape wrote:
> In the long run:
>  - Provide deb's and rpm's

Do we have a starting point for this packaging effort? (A github repo
somewhere perhaps?)

If not, for .deb, one option would be to start from the existing
packages in Debian.

Tony

Currently the all-in-one is packaged to look like an application on macOS, which is very clever but seems to make for many problems. Does it actually need to be like that?

Would it work if we simply made our all-in-one package be a directory with the image/changes/sources and subdirectories for each vm? Hmm, well there is a possible issue with 32/64 bit confusion - ok, so how about something like
/
   SqueakMac.app
   SqueakWindows.bat
   SqueakLinux.sh
   .. Ubuntu etc as required
  /data
       squeak.image
       squeak.changes
       squeak.sources
/vm
   /linux
   /windows

So you see scripts relating to your OS. They start up the appropriate stuff. They ought to be able to work out 64bitness.

We also really should work on the startup experience some more. Marcel added some nice beginnings for 5.1 but I have always strongly believed that the default image needs to be locked and set up such that pretty much the first (or even only!) thing you can do is save a new image to actually work on. Hooking up a file location chooser instead of a simple singe line text entry box would help quite a lot there.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Logic:   The art of being wrong with confidence...

Ah I forgot:

On 27.02.2017, at 13:00, Tobias Pape <[hidden email]> wrote:

> Hi,
>

Motivation:
 - This thread: http://forum.world.st/Attempting-to-run-Squeak-all-in-one-download-on-ubuntu-linux-tt4936001.html
 - This issue: https://github.com/dalehenrich/metacello-work/issues/427#issuecomment-281919088
 - This thread: http://forum.world.st/Problem-with-Squeak5-1-16549-32bit-All-in-One-tp4935860.html
 - This thread: http://forum.world.st/Squeak5-1rc2-16535-32bit-fail-to-open-in-macOS-Sierra-tp4934524.html
All these are at lease partially because of the way AIOs work and how we deliver them

Moreover:
 - This old post: http://forum.world.st/All-in-ones-tp4662358p4662665.html
 - My experience from building All-in-ones for Seaside and for bi-annual courses at HPI that use Squeak.


Also:
 - It does not work on ARM/RaspberryPi
 - It does not work on BSDen (yes, I know it's rare)
 - It does not work on RISC OS (Sorry, tim)
 * Points above are no problem _individually_ (again, sorry, tim), but in their combination.

Hi Tobias,

AIO provides a compact example file of everything needed to deploy an
application on each of the top platforms.  For no more than its
instructional value, it is something worth keeping, IMO.  Having an
AIO is independent of having platform-specific downloads.  Before
making any other reasons besides the first one (cumbersome), all of
the other ones are unnecessary for everyone to have what they want.  I
thought someone recently announced that the All-In-One is getting
built automatically..

I like Tim's idea.  We already need to solve the problem of
conflicting directory structures to resolve between 32 and 64-bit
VM's.  Maybe we can solve that issue and the MacOs Sierra issue
simultaneously.

Best,
  Chris

PS -- Following up those links:  the first one is Hari's, we've knowm
about the 32-bit library challenges for a decade, it is unrelated to
the AIO and with 64-bit around the corner, it will melt away soon.
The 2nd link was something about Metacello nothing to do with the AIO.
The 3rd and 4th were about MacOs Sierra.  We should add
platform-specific apple install for Sierra, whose users may not even
care about the AIO anyway.  But others will..

On Mon, Feb 27, 2017 at 3:39 PM, Tobias Pape <[hidden email]> wrote:

A big, important thing that is just plain Wrong, with a capital Duh, is that when using the mac package (or AiO) when you save an image it goes into the Contents/Resources folder, buried deep within the application file where *no one will ever find it*. Re-running the application in an attempt to get back to your work simply (and arguably correctly) runs the default image.

No.

Just fricken no.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"E=Mc^5...nahhh...E=Mc^4...nahh...E=Mc^3...ah, the hell with it."

On Mon, Feb 27, 2017 at 01:00:29PM +0100, Tobias Pape wrote:
> Hi,

Hi Tobias,

Personally I prefer the traditional image/changes + sources + VM as a
distribution artifact. This is now nicely documented on squeak.org in the
"Advanced" section of the Downloads tab. I do not see anything really
advanced about this, but it makes sense as distinct from "Quick Download".

>
> here's a bullet point list:
>  - macOS Sierra needs a special vm compared w/ previous ones
>  - macOS Sierra makes it hard to _just run_ downloaded bundles/All-in-ones
>  - all-in-ones look ugly since Yosemite due to new requiremens for code signing.
>  - we have some indirection in the shell scripts for the linux variant
>  - we still have this strange LD_LIBRARY_PATH dance that apparently fails on
>    newest Ubuntu (see recent mail)
>  - occasionally, we have people from BSDen who also want to use Squeak.

I view the All-In-One, or similar "Quick Download" options, as convenience
distributions. They require maintenance in order to remain useful for the
major OS platforms, but they are useful and convenient when they do work.

I have no expectation that they will remain useful or convenient several
years after their initial release, and I have no expectation that the
community will have the resources or motivation to maintain them for the
long term.  But that does not matter too much as long as I can run the
original release image using some reasonable VM for whatever platform I
happen to be using.

>
> So, I'd propose:
>  - Ditch the AOIs.

I like the All-In-One releases, and I think we should keep them as a
convenient "Quick Download" option as long as someone is willing and able
to produce them. We should not ditch the AIOs, but we should also not expect
them to serve as a reliable base release artifact that will be useable for
many years on a broad range of platforms. That is not going to happen.

>  - Deliver macOS bundles as DMG, not as Zip, so as to force people to
>    move the bundle, so that macOS Sierra is happy to run stuff.

That sounds like a good idea.

> In the long run:
>  - Provide deb's and rpm's

For VM installation, yes. That is definitely a good idea for Linux
distributions, although historically we have not had people (myself
included) with the time and motivation to actually do the work.

For Squeak release distributions, I don't see much value. If keeping
the AIOs up to date is already too much work, then I do not see how
maintaining Linux distributions would be any easier.

Dave

On Mon, Feb 27, 2017 at 06:27:13PM -0800, tim Rowledge wrote:
> A big, important thing that is just plain Wrong, with a capital Duh, is that when using the mac package (or AiO) when you save an image it goes into the Contents/Resources folder, buried deep within the application file where *no one will ever find it*. Re-running the application in an attempt to get back to your work simply (and arguably correctly) runs the default image.
>
> No.
>
> Just fricken no.
>

+1

Dave

Hi

On 28.02.2017, at 10:03, Fabio Niephaus <[hidden email]> wrote:

> I'd suggest to start a new GitHub repo and use TravisCI to generate and deploy the deb/rpm to Launchpad. Happy to help setting this up...

Hadn't thought of Launchpad :D
But we once actually provided debs:

http://files.squeak.org/debian/

More specifically:
http://files.squeak.org/debian/dists/etch/installed/

I also thought of [aptly](https://www.aptly.info/) to manage our debs…

Best regards
        -Tobias

On 28.02.2017, at 03:14, Chris Muller <[hidden email]> wrote:

I know, I also built AIOs, automatically and manually.
And they are a pain to get right.
I know of no other programming environment/language/system that provides a one-size-fits-all download
(Except some .jar files, like Jenkins, but thats another pain)

>
> I like Tim's idea.  We already need to solve the problem of
> conflicting directory structures to resolve between 32 and 64-bit
> VM's.  Maybe we can solve that issue and the MacOs Sierra issue
> simultaneously.

Nope. We can't make this sierra-proof.

>
> Best,
>  Chris
>
> PS -- Following up those links:  the first one is Hari's, we've knowm
> about the 32-bit library challenges for a decade, it is unrelated to
> the AIO and with 64-bit around the corner, it will melt away soon.

My point is not the 32/64 problem here but the LD_LIBRARY_PATH dance etc.pp.
that would be solved by having proper distribution specific downloads.

> The 2nd link was something about Metacello nothing to do with the AIO.

But sure, because the metacello problem manifested by two things
 (a) package-cache was only root-writable
 (b) We had no proper error-reporting for this case
But why did (a) happen? because our architecture compelled the user into thinking
running squeak with sudo once was necessary.
I think this is at least in part an error of the AOI. (not solely, of course, but it contributes)
 
> The 3rd and 4th were about MacOs Sierra.  We should add
> platform-specific apple install for Sierra, whose users may not even
> care about the AIO anyway.  But others will..

The Sierra thing is (apart from the VM problem due to Apple not being able to communicate)
that Apple decided to place AppBundles that are just downloaded or unpacked in the Downloads
folder are put into a _read only temporary_ location before run so we can no longer open
images/changes read-write. How should we solve this?
 - Put the app-bundle in a read-only DMG and have the user move it somewhere else when
   opening the DMG. Thats the only way that reliably works. And that would _Also_ work for
   all other macOS or OS X versions.

So to summarise:
 - The problems with 32/64bit and heartbeat thread activation would only reliably be solved by
   providing system packages (debs/rpms with proper dependencies) for Linux distributions
   (==> not AOI-able)
 - The problem with OS X would only reliably be solved by providing the AppBundle in a
   read-only DMG. (==> not AOI-able as nobody else can open DMGs)
 - That leaves Windows, wich would tremendously benefit from cleaned-up directory structure
   (or a proper installer, for that matter, which wouldn't be too hard. Etoys did that)

I sure see  the value of an AOI (Etoys nicely names it 'Etoys to go', which I find a better name anyway)

So if someone comes up with _better_ solutions to the problems mentioned above, sure, lets do it.

But currently, we only frustrate newcomers.

Best regards
        -Tobias

On 28.02.2017, at 03:27, tim Rowledge <[hidden email]> wrote:

> A big, important thing that is just plain Wrong, with a capital Duh, is that when using the mac package (or AiO) when you save an image it goes into the Contents/Resources folder, buried deep within the application file where *no one will ever find it*. Re-running the application in an attempt to get back to your work simply (and arguably correctly) runs the default image.
>
> No.
>
> Just fricken no.

Yep. We should adopt a copy-default-image-to-know-location-and-run-from-there-subsequently-if-no-image-given-on-commandline :D

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> "E=Mc^5...nahhh...E=Mc^4...nahh...E=Mc^3...ah, the hell with it."
>
>
>