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.