Blog post on how to create AppImages: feedback appreciated

[fusion809]

Hi,

I have been writing a blog post on creating AppImages on my Jekyll-powered blog, The Hornery and I thought you would like to read it and offer suggestions before I publish it. The post isn't published, to view it one has to run (assuming git and bundler is installed):

git clone https://github.com/fusion809/fusion809.github.io
cd fusion809.github.io
bundle install
bundle exec jekyll serve -I -D --future

from the repo's top-level directory. Then open your web browser to http://localhost/how-to-create-appimages/. It is not quite completed yet, but the background section is likely finished so if you can check it for errors that would be appreciated. If you're too busy to help, that's fine, I understand.

Thanks for your time, Brenton

[probonopd]

Hi Benton, thanks for taking the time, here are some thoughts on your text; feel free to incorporate or disagree or ignore.

fusion809.github.io/pages/appimages/appimages.md All that is required to run is them is for them to be made executable

Unless the optional appimaged daemon is used, which removes the need for making AppImages executable.

fusion809.github.io/pages/appimages/appimages.md fusion809.github.io/_drafts/APIM/01-introduction.md

cross-distribution packaging format (CDPF)

Would rather call it a distribution-independent bundling format. AppImages are not really "packages", in the traditional sense, are they?

fusion809.github.io/pages/appimages/appimages.md probonopd's AppImages Bintray Repository

A collection of example AppImages. Keep in mind that the AppImage format and AppImageKit are designed with upstream packaging in mind, where end users can get binaries directly from application authors without any third parties in between users and authors.

fusion809.github.io/_drafts/APIM/04-yaml.md

package is deprecated; do not mention it, should use packages instead. bintray should be binpatch. binpatch and union are mutually exclusive (only one or the other may be used but not both). dist: Nothing newer than debian oldstable or the oldest still-supported LTS release should be used.

fusion809.github.io/_drafts/APIM/02-background.md

What you call <FS> is called a $PREFIX in some contexts.

The target distribution ideally should be an old (especially with regard to the age of the software in its official repositories), yet still supported distribution.

To be precise, it should be the oldest distribution the creator of AppImage is still targeting as a base system. Ideally, this is the oldest distribution a certain application can still be built for. For practical reasons, it is usually sufficient to target the oldest release that is still supported by the distribution provider; assuming that users will upgrade the distribution when it is no longer supported.

target distribution

Maybe it makes sense to distinguish between a distribution release (= the version of the distribution a package was compiled on and was originally intended for) vs. the target systems of the AppImage (= the distributions and versions the person making the AppImage is trying to target).

Reasonable choices for a target distribution include

I would not name concrete releases but relative ones, e.g., "debian oldstable" is always the current version minus 1, "oldoldstable" is the current version minus 2. Ubuntu will always have an "oldest still-supported LTS release". This way the suggestions will still be relevant in a couple of years.

fusion809.github.io/_drafts/APIM/03-recipes.md

Technically speaking, the yml files are parametrizing the generic (abstract) meta recipe, hence removing the need for the person writing the file to type a lot of repetitive code that is common to all recipes. As a side effect, improvements in the meta recipe propagate to all yml files this way.

fusion809.github.io/pages/glossary/02-basic-definitions/27-cross-distro-packages.md contains all the libraries, executables, desktop configuration files, icon files, etc. used by the application it provides

"...that cannot reasonably be expected to be part of the target systems in a recent enough version". This is important; otherwise the text might suggest that all dependencies are bundled which some people might consider as bloat.

Flatpak

Flatpak currently does not run on Live CDs or Live ISOs, so are not suitable for running an operating system and applications from, e.g., a Live system on a USB stick. Also, software in its installed form is different from software in its downloadable form, making it difficult to e.g., move software from one machine to the next in an offline environment. In contrast, AppImages can be run on Live systems and can easily be moved from one machine to another thanks to the "one app = one file" format.

Snap

While conceptually similar to AppImage, Snap requires a runtime to be present on the base system, which happens to be a minimal Ubuntu distribution. So effectively you are running the application on top of Ubuntu on top of whatever distribution you are running. In contrast, AppImages do not need a special runtime besides the target system.

fusion809.github.io/_posts/2016/08/IDE-TE/11-emacs.md

The GNU project traditionally has been more concerned with the openness of their source code rather than providing a polished end-to-end user experience for people who do not want to compile and is consequently not providing binaries on their download page.

[fusion809]

They are packages in a loose sense as they are a distribution of files (or what you could call a package) for running an app, as I also lump binary archives (like zip or tarballs) in as CDPFs. I call them cross-distribution packaging formats partly also as that's the term I use for flatpaks and snaps which are more definite packaging (as opposed to bundling) formats. It's more so I can talk about these other cross-distro packaging formats and AppImages collectively without having to say CDPFs and CDBFs, rofl. Anyway, that's a fairly minor semantic thing. The rest I'll implement, thanks.