search

AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.76k stars 563 forks source link

Include the promised `extract` and `inspect` functions into `appimagetool` #572

Open KurtPfeifle opened 6 years ago

KurtPfeifle commented 6 years ago

The appimagetool --help utility prints:

   appimagetool [OPTION...] SOURCE [DESTINATION] - Generate, extract, and inspect AppImages

However, the inspect and the extract features are currently only promises about a bright future, but not implemented. (Unless you count the --list in as part of inspecting an AppImage...)

I've heard arguments to drop even the plans to include functionality for extracting (and possibly inspecting) AppImages. The argument is that type 2 AppImages already support the --appimage-extract option, they can "self-extract".

Ok, then rename this one to appimage-builder or some such...

However, I strongly request to have an independent tool to extract and inspect AppImages. These are my reasons:

  1. I want a tool which I trust more to investigate an AppImage I just downloaded and have not confidence to make it executable to run it. I strongly feel we should have the ability to make it very easy to extract AppImages which are not set to self-execute yet!
  2. It could potentially help to extract AppImages which are buggily implemented and cannot self-extract.
  3. It should be able to extract type 1 AppImages as well (who knows, how long these will still be around??)
  4. You promised the function in above quoted --help output.
  5. You are working on a library which could be used by third-party applications (like Distro App Stores or Software Centers) -- so why not use that same library in all appriate AppImageKit tools?
  6. If you "Eat Your Own Dog Food!" -- you'd notice many bugs which sneak into a release faster as well...

The inspect part of this should make it easy to check for some common problems and shortfalls which AppImage packagers still fall prey of. It should also enable users to collect relevant data points to report to an AppImage packager when they have a problem.

TheAssassin commented 6 years ago

The inspect part needs a conceptual discussion, we don't really know how to build that feature, and I wouldn't expect that too soon.

The extract part is planned to be added within this sprint. I've always supported the idea of being able to extract AppImages without executing them, and now there's a chance to implement this. It's rather simple, all the functionality is available already, we just need to copy the code from the runtime, and add it to the argument parser.

probonopd commented 6 years ago

The inspect part needs a conceptual discussion

With "inspect" I was thinking simply of listing (rather than extracting) the files in the AppImage, not more.

Alexey-Akishin commented 6 years ago

I was very surprised when instead of extracting the AppImage appimagetool just displayed "To be implemented" message. When I googled about this, I arrived here. Extracting AppImages without executing them would really useful, hopefully somebody eventually finds time to implement this feature.

probonopd commented 6 years ago

@Alexey-Akishin noted. In the meantime, you can run ./Your.AppImage --appimage-extract. Can you describe your use case? Maybe we already have a workaround solution.

TheAssassin commented 6 years ago

@probonopd we (@azubieta and I) suggested to implement an extract functionality in appimagetool long time ago... you didn't want it. We could quickly build some sort of extraction tool, I guess, if you don't want it to be in appimagetool, although I think appimagetool is the perfect place for it.

probonopd commented 6 years ago

Let's say I didn't see it as an urgent priority because we already can do it. What worries me most is that if we implement it, we need to implement it for all types of AppImages. If it's cheap to do because libappimage already has all the functionality, then sure, let's go ahead and do it.

TheAssassin commented 6 years ago

We don't necessarily have to implement that for all types. Who says that? I would appreciate a way to extract stuff built by that appimagetool using appimagetool. For type 1, we have the good ol' AppImageExtract, which still works. Or people just use xorriso -osirrox directly.

Let's say I didn't see it as an urgent priority because we already can do it.

That's not quite true. Having to make AppImage executable to see its contents is a huge security issue.

probonopd commented 6 years ago

Again, and again, and again, type 1 is not deprecated (and never will be, because it's the format all OSes can easily access and Live ISOs come in). It is still one of our supported formats.

TheAssassin commented 6 years ago

Where did you read "deprecated"? All I am saying is we have a tool that solves the issue for type 1, so why pull in dependencies into appimagetool although we just need a solution to extract type 2 AppImages?

probonopd commented 6 years ago

AppImageAssistant is deprecated, and has been for a long time. We use libarchive to extract type-1 AppImages. See appimaged.

TheAssassin commented 6 years ago

xorriso does the same thing, and doesn't pull in unnecessary dependencies...

probonopd commented 6 years ago

Don't we have ISO9660 extraction in libappimage yet? Then we should do that...

TheAssassin commented 6 years ago

The point is, AppImageExtract works fine. Why reinvent the wheel?

probonopd commented 6 years ago

To have everything neatly in one place.

TheAssassin commented 6 years ago

Not really necessary IMO.

TheAssassin commented 5 years ago

Related: #830.