Relationship to AppDir specification at docs.appimage.org/reference/appdir.html?

[kossebau]

There is no hint which one overrules the other, while some content is contradicting.

Examples:

• icon file as "PNG with 256x256 or 512x512 pixels" vs. "in the best available quality, ideally a vector graphic"
• "SHOULD contain exactly one $APPNAME.desktop file in its root directory with $APPNAME being the name of the payload application" vs. "The name of the file doesn’t matter, as long as it carries the .desktop extension."
• "MAY contain an $APPNAME.png file in its root directory" vs. "These four types of entries MUST be contained in the AppDir" (one type being myapp.)

[probonopd]

I am not entirely happy with the content of docs.appimage.org/reference/appdir.html since it might be (mis-)interpreted that we own the AppDir spec. Which is not the case.

https://github.com/AppImage/AppImageKit/wiki/AppDir says:

The AppDir format for application directories was first introduced by ROX Filer. http://rox.sourceforge.net/desktop/AppDirs.html

Over time, we have been habitually extending the AppDir format, for example by using files for desktop integration if they happen to be in usr/share. But this has really never been formalized so far.

[TheAssassin]

@probonopd I've said it quite a lot of times, but let me repeat myself once again: We do own this specification, as we basically inherited whatever ROX have invented, and extended it in many regards.

[TheAssassin]

By the way, the History section is more appropriate than the outdated wiki page:

History

The AppDir format has first been described by ROX Filer, and has since been extended by the AppImage project to suit their needs.

The General Description contains info on what is being used from the ROX description, and that we don't use a couple of entries but introduced our own:

These two entries have been re-used from ROX Filer’s specification. ROX Filer actually specifies additional (but optional) entries, however, AppImage doesn’t use these. Instead, the following ones have been introduced:

Therefore, my point is we actually inherited their spec and developed on it. Call it a fork or a new version, but we're not using theirs but have our own. Therefore I felt it was time to write a "specification" for it. Please show me why you think that is not the case. I want to understand your thinking here.

[probonopd]

Once one writes a spec (or a new version of a spec) for something, things are no longer "just by convention" but they have to be followed. So I want to write specs once things have settled enough and one has experimented enough to conclude how things should be done.

To give you an example:

When I started with AppImage, I wanted to have self-contained application bundles similar to the Mac. I could have invented a random new directory structure or adopted the format from the Mac, with .app/Contents/Resources and such. I did not do that because I thought that no one (especially not Gnome and KDE) would implement a random new directory structure format by a random guy. So I searched around for prior art and the first thing I found was ROX AppDir, along with ROX Filer which even displayed and operates them nicely. I thought "exactly what is needed" and used that.

Only over time I noticed that when putting together ROX-style AppDirs, it was convenient for me to have a FHS-style $PREFIX (usr/bin/...) somewhere in the AppDir, and I ended up doing this quite frequently. But it is undefined where to put this structure, or whether one is needed at all. In the beginning it was mere coincidence that many of the AppDirs I made (especially those converted over from pre-existing binary packages) contained such a structure. And I didn't want to put the burden of making such a structure to all AppDirs.

As time progressed, we introduced desktop integration with the optional appimaged daemon and it turned out that to do this, the appimaged daemon (and other such tools) need to know which files from inside the AppDir to copy into the system (it would be better if no such copying would be needed in the first place, but that's another topic).

Just because most of the AppImages I had made so far were already coincidentally using a FHS-style $PREFIX (usr/share/...) in the root directory of the AppDir (even though this was never specified anywhere), I made the appimaged daemon use that. Snappy, for example, decided otherwise and introduced a separate "exports" directory where you put stuff into that is supposed to get integrated into the system.

Some considerations should be made (and have never explicitly been made so far) if we really ever want to bring out a new AppDir spec:

• Should we really mandate a FHS-style $PREFIX (usr/bin/...) somewhere in the AppDir, and why? Or should we go the Snappy way and have some "exports" directory?
• Is it possible to merge the AppDir spec with the Snappy structure, so as to make Snaps that are also valid AppImages? (the idea is at least 2.5 years old)
• Is it possible to merge the AppDir spec with the Apple-style .app directory structure that is also used by OPENSTEP? E.g., why not have Contents/Linux_x86-64 like they have Contents/MacOS...

and the like.

So, before we officially(!) "extend" the AppDir spec, I'd like to see some thought to go into those things. Just because I pragmatically started doing some things (usually using the least complex, most straightforward way) it doesn't necessarily mean it's the right thing to do.

Also, I still believe that KDE, Gnome etc. should support an AppDir-like bundle structure properly and natively, entirely independently of AppImage. So they are stakeholders in such a discussion, which is necessarily broader than just how the directory format looks like.

[kossebau]

My quick brainstorm take on things is this:

the content of an appimage can be possibly split in three types:

1. application payload (all the content needed by the app itself to run)
2. application metadata (info as useful for store, installation, updates)
3. system integration data (things which will be copied into the system, not used by app itself)

Some content might fall into more than one type, if reuse is wanted.

The type 1 depends on what structure the application software itself expects/relies on (as also prepared by AppRun), both in format of content and where to find in the appdir filesystem.
The type 2 is mainly dependent on what the AppImage spec defines, as one-sided offer to/contract with managers of AppImage instances (e.g. stores & installation managers), so no external requirements on format and filesystem location.
The type 3 is dependent in the content and format in what is needed for the systems supported, but not where things are placed inside the appdir filesystem and in which format, as long as things can be generated from it as needed for the system to integrate with.

From this, to allow flexibility for the future as well as avoid unneeded constraints on the specification of appdir/appimages, having type 2 and type 3 each in some own, separate structure and format allows to decouple things. E.g. if one day non-xdg-fs-based application software is distributed in AppDir format, metadata and integration data would not be affected, as they are independently defined and stored/accessed, so those handlers only looking at type 2 and type 3 data can work as before.

To avoid data duplication, if some app payload files can be reused for metadata & system integration, they could be sym-linked/hard-linked from the respective other locations. As it already is done often with the .DirIcon and $APP.desktop files.

When it comes to (partial) compatibility to existing self-contained application container formats, I am undecided if one should try to go for that, as it might result in also only partially working solutions if those try to do cross support.
Having an own format is fine, as long as it is well designed and easy to support. It might actually be of an advantage, if it results in solutions which work better.
Compatibility might be wanted though to be considered on formats and ontologies e.g. when it comes to metadata, so things can be easily mapped e.g. when converting/importing from other app formats, like pixel icon sizes, icon image formats, category/tag types, etc.

Then I am also a fan of release often & early, also when it comes to things others rely on, like specs. Of course this results in unavoidable breaking changes now and then when backward compatibility is not easily possible, rendering old efforts/artifacts no longer working, but that is the price of advancing.
For me it mainly boils down to proper communication and a bit orchestrated roll-out. If changes are announced in advance, if changes bring obvious advantages, if stakeholders are in the loop, if dates are met, then most people are fine with changes. Sure they will be some moaning who made themselves comfortable with the presence, but then they could/should just fork things and shut up ;)

[TheAssassin]

There's nothing like "opinions" here. We do specify our own list of requirements for AppDirs already. You can't reject this fact. It's very important to stand behind this and actually also specify that, that way you have a document you can share with others and refer to in discussions.

[probonopd]

We can either:

• In the AppImage spec, state that into an AppImage goes a ROX AppDir, that MUST and/or SHOULD have certain additional properties (this was my original approach); or
• In the AppImage spec, state that into an AppImage goes a self-defined "AppDir 2.0", that should get something equivalent to the AppImageSpec but regarding AppDir (using the same language like the AppImageSpec)

Which approach do we want to use?

[TheAssassin]

The first approach is equal to the second, but less obvious and probably harder to read/understand. I'd go for the second.

By the way, I never said the AppDir spec does have to stay in that shape. I'm fine with rewriting it. We could move it into this repo even.

Why does it have to be called 2.0?

[probonopd]

Could also be 1.x, if we break nothing from ROX's version.

[TheAssassin]

To be investigated, I guess. Do you want to give writing an AppDir spec based on my work in the docs a try? Version can be determined later.

[probonopd]

As said before, I try to avoid unnecessary "admin" work "wie der teufel das weihwasser". I think it's sufficient to slightly tweak AppImageSpec like @kossebau has started doing.

[TheAssassin]

Disappointing. We really need better and more specific documentation. Specifications are documentation...