Linux distribution as an AppImage

[philipzae]

Would be great if you could provide an appimage build along side the deb and rpm builds.

Check out its benefits here
https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

You can find more info about integrating it into your github builds here
https://github.com/probonopd/linuxdeployqt#sending-pull-requests-on-github

[bengotow]

Hey! Thanks for reporting this—we're planning to stick with Snapcraft for now because it allows us to deliver automatic updates across all Linux distros. (We're actually planning on hiding the deb / rpm builds as soon as the snapcraft version is fully tested.) The autoupdate thing is huge for us—Linux users are typically 1-4 versions behind because we haven't been able to update the app automatically on smaller linux distros eg ArchLinux (based on our automatic crash reports), and it causes quite a bit of additional support load. I'll leave this open but we'd really need a strong reason to invest time in another package format achieving most of the same goals as snapcraft but without first-class automatic updates.

…

On Nov 16 2017, at 2:08 pm, philipzae ***@***.***> wrote: Would be great if you could provide an appimage build along side the deb and rpm builds. Check out its benefits here https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (#344), or mute the thread (https://github.com/notifications/unsubscribe-auth/AA_TnO3NiY1DVR07jCtgn5bDS8rHiYvuks5s3DPogaJpZM4Qgdl3).

[TheAssassin]

@bengotow self-updating software can be nice, and there's tools that can do the same for AppImages.

In case you are using electron-builder (to generate the .deb package that is consumed by the snap build), please beware that it can produce proper AppImages without any real additional effort (just need to call it the right way).
Furthermore, they've built their own auto updater thing for Electron AppImages, see electron-userland/electron-builder#1138 for details.

Although, as the main author of AppImageUpdate (which will receive a self-updating feature as soon as possible, too) I am not entirely happy about Electron's decision to build their own system (I'd have preferred to see them using libappimageupdate), however, to my knowledge it works fine, and suffices your auto update constraint.

Another very useful AppImage use case might be continuous deployment. Many projects, involving all AppImage tools, but also other big projects like Subsurface use it to ship binaries for the latest changes to the users, and with AppImageUpdate, people can easily update their software.

So, if distributing releases is not a use case, maybe those nightly builds are one you might even find useful for alpha/beta testing.

[philipzae]

Hi @bengotow

Hey! Thanks for reporting this—we're planning to stick with Snapcraft for now because it allows us to deliver automatic updates across all Linux distros.

Just wanted to bring this to your attention if you didnt already know it, Snap is only supported in Debian 9 which released 6 months ago, while not supported in Debian 7 and 8.

[ringwald]

Any updates on this? I really like your mail client, but am not going to install a special OS just to read to email, when Nylas and Thunderbird are workable. I am running NixOS 19.03, which does not support snaps, but can use flatpaks, which you also do not provide. I guess I will be sticking with Nylas for the foreseeable future.

[oniGino]

Hey! Thanks for reporting this—we're planning to stick with Snapcraft for now because it allows us to deliver automatic updates across all Linux distros. (We're actually planning on hiding the deb / rpm builds as soon as the snapcraft version is fully tested.) The autoupdate thing is huge for us—Linux users are typically 1-4 versions behind because we haven't been able to update the app automatically on smaller linux distros eg ArchLinux (based on our automatic crash reports), and it causes quite a bit of additional support load. I'll leave this open but we'd really need a strong reason to invest time in another package format achieving most of the same goals as snapcraft but without first-class automatic updates.
…
On Nov 16 2017, at 2:08 pm, philipzae @.***> wrote: Would be great if you could provide an appimage build along side the deb and rpm builds. Check out its benefits here https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (#344), or mute the thread (https://github.com/notifications/unsubscribe-auth/AA_TnO3NiY1DVR07jCtgn5bDS8rHiYvuks5s3DPogaJpZM4Qgdl3).

Building and maintaining an AppImages is fairly trivial, if I file a PR for build automation of app images would your team consider merging?

Also You probably know by now, but Snap actually only works on Ubuntu distro it is not universal.

Let me know I'll gladly put something together.

[CodeMouse92]

We are in the process of migrating issues to Discourse, which can better facilitate discussion and discovery, and so GitHub Issues can focus on issues that are confirmed and slated for resolution in the near term. Learn more about the changes here.

As part of this, we've migrated this issue to Discourse:

https://community.getmailspring.com/t/linux-distribution-as-an-appimage/388/4

Please consider joining that community and continuing the discussion there! Votes on the feature suggestion on Discourse will increase the likelihood we implement this.

@philipzae @TheAssassin @oniGino: if you join and reply to the issue, the moderators can make an effort to reassign your posts to you, so you get the credit for them.

@oniGino @TheAssassin I would particularly like your updated takes on that thread.

We're closing and locking the issue here as part of this migration. Rest assured, this doesn't mean the issue is being discarded or ignored.

We hope to see you on Discourse soon!

-The Mailspring Team