Posposal: a new version of the specification

[mijorus]

Hi there,
I'm the developer of gear lever, application to manage appinages.

The last couple of years I received multiple feature requests for my app, things that I've learnt about the user experience that I want to propose here, as a new or updated version of the spec.

1. All Appimages must be able to return their metadata without being fully exacted, which a command like option that must be built in
2. The current update system is ok but is limied, I would propose embed a static INI file inside the appimage package, that can be retrieved with a terminal command
3. Appimages should be able to list their features with a terminal command, for example: updates, desktop-integration etc .., Right now, there is no way to know if an app supports the --appimage-extract or not.
4. Should not rely on fuse2 anymore, some developers already found a way to do this

Let me know what you think

[mijorus]

@kem-a your feedback on this would be great also

[Samueru-sama]

All Appimages must be able to return their metadata without being fully exacted, which a command like option that must be built in

--appimage-extract supports partial extraction with simple globbing.

The current update system is ok but is limied, I would propose embed a static INI file inside the appimage package, that can be retrieved with a terminal command

--appimage-updateinfo???

Appimages should be able to list their features with a terminal command, for example: updates, desktop-integration etc .., Right now, there is no way to know if an app supports the --appimage-extract or not.

--appimage-help?

Should not rely on fuse2 anymore, some developers already found a way to do this

The old runtime has been deprecated for a while

[mijorus]

Thanks for the reply

--appimage-updateinfo does this already exists?

Also, reliance on zsync is not great IMO, app developers and especially companies might not be interested in implementing zsync in their release workflows

[Samueru-sama]

--appimage-updateinfo does this already exists?

2018

Also, reliance on zsync is not great IMO, app developers and especially companies might not be interested in implementing zsync in their release workflows

The .zsync file should be made automatically, we do that already.

I agree the experience is not good outside of github pkgforge-dev/AppImageUpdate#1

[mijorus]

--appimage-updateinfo does this already exists?

2018

This is great, I did not know about this.
The problem I have is that since they're all Type2, there is no way for me to know if if an app created with appimagetool and if it is using a version of appimagetool newer than November 2017.

https://github.com/AppImage/AppImageKit/wiki/Extracting-AppImages/04bd746fc0c8d9de41193172e8a54e681e119ea3

That's why I wanted to propose a new version in the first place, a Type3 specification ensures that a valid appimage MUST implement all the commands reported on that wiki.

Right now, if an app does not implement one of those commands, it might just launch when I am trying to extract the desktop file for example

[Samueru-sama]

That's why I wanted to propose a new version in the first place, a Type3 specification ensures that a valid appimage MUST implement all the commands reported on that wiki.

#56

Right now, if an app does not implement one of those commands, it might just launch when I am trying to extract the desktop file for example

I mean, even if we get a type3 spec, you are still going to have that issue since not everything is going to update instantly.

If you are worried about the application launching you can just use bwrap to perform the extraction.

[probonopd]

Hi @mijorus, thanks for sharing your thoughts.

First up, we are trying to keep the AppImage file format as stable as possible. We don't want to create a "moving target", but something that you can depend on for a long time (think decades, not months). We realize that most developers don't appreciate constantly changing infrastructure.

So while there may be a type 3 specification somewhere in the future, this is not something that is going to happen overnight.

To your points:

All Appimages must be able to return their metadata without being fully exacted, which a command like option that must be built in

That is already possible by using the --appimage-... commands or by selectively listing/extracting just individual files. Can you share details about your use case?

The current update system is ok but is limied

In which way is it limited? Can you share details about your use case? It is possible to extend the format without breaking the conventions for the existing schemas.

I would propose embed a static INI file inside the appimage package

We don't want that. The AppImage update information is not part of the main compressed filesystem because we understand that the hosting location (servers) of existing AppImages can change, and we don't want to have to repackage the entire AppImage filesystem in that case. With the current format, one can just update the update information without having to repack the whole AppImage if e.g., the server URL changes.

Appimages should be able to list their features with a terminal command

--appimage-help as mentioned above.

Should not rely on fuse2 anymore, some developers already found a way to do this

The official AppImage type 2 runtime hasn't needed libfuse2 for a long time. I don't know why people are still talking about this.