Completely portable appimages

Using AppImages
1

Hi,

Would it be possible to have completely portable appimages? This could be achieved the following way imo:

  1. Have an option when packing the appimage to always use portable mode, so you don’t need to use the command line all the time.

  2. This one is a lot harder. I know most people won’t like this so i guess it should be optional but it would be really nice to have. Could it be so that when an appimage mounts its appdir, it also mounts a separate DataDir and uses that as a portable home / config, in such a way that the appimage file also contains all it’s data? Would it even be feasible? Perhaps also add a command line option to quickly delete the DataDir if the user wants to get the app to the original state. This would be the ultimate One-file app.

Thank you. I love what you’re doing. AppImages are what convinced me to finally jump to Linux an year ago and I’ve never been happier with an OS.

2

By design we want AppImages to be read-only.

But all you need to do is to create a folder next to the AppImage with the exact name of the AppImage plus the .home extension. Then everything that would normally be saved in $HOME will be saved there instead.

Does that do what you need?

3

I am aware of that functionality but it feels like just going halfway. If you have a directory with a lot of appimages it will become very messy. Also I can’t expect my users to create those directories by default.

I really want my apps to be portable so I would really like for them to be portable by default, without having to create any directories.

I would also love it if the data would be included into the appimage file itself. It would still be read-only in all the ways that matter.
The unionfs that gets written to could be kept separate and the app could be reversed to its original state with a command line argument like --appimage-reverse or something.
This would make the format extremely convenient and clean to use.

I’m gonna try to do it myself and better understand the format in the process.

Also I can’t stress this enough,
Thank you for appimages man, you are singlehandedly making linux 10 times more accessible. Cheers.

În lun., 16 aug. 2021 la 11:29, probono via AppImage <appimage@discoursemail.com> a scris:

4

It’s probably possible, but it brings a lot more problems than what it’s probably worth.

Main issues being:

  • They are not the “true” AppImages, as in they do not follow the basic structure of existing AppImages, so no standard software for dealing with them would work
  • The storage space in them would be limited as SquashFS would be out of the question because the image needs to be R/W, so you’d have to go with a more typical FS like EXT4
  • Compression would probably be out of the question as well, as far as I know BTRFS and NTFS are the best options for seamless R/W compression and at least BTRFS has a large footprint so it would bloat the size of the program
  • Accessing the data would be harder, due to requiring it to be mounted

If you’re only interested in making them (or converting existing AppImages) for personal use and understand the drawbacks, you should go for it. Might be kind of cool for a program that always stores the same amount of data for configuration, although IMO having a directory accompanying the AppImage doesn’t really seem cluttered

5

Interesting idea, but consider how PortableApps on Windows does this. They have a program that “installs” a portable app to a thumb drive or any directory. They automatically set up the needed directories. In theory, you could do something similar for users. Create a program or script they can use to set up the needed directories for each AppImage they “install”, with a file structure like:

./
./AppImages/
./AppImages/someportableapp/
./AppImages/someportableapp/someportableapp.AppImage
./AppImages/someportableapp/someportableapp.AppImage.home/
./AppImages/someportableapp/someportableapp.AppImage.config/

If I understand how AppImages work, this should just work automatically.

6

AppImage can work in a very similar way, but you need to create the .home or config directory (not both!) if you want to use this feature. You can do this by creating the appropriately named directories by hand or by using --appimage-portable-home or --appimage-portable-config once.

If I understand how AppImages work, this should just work automatically.

No. By default, AppImage does not change where applications write to.

7

folder next to the AppImage with the exact name of the AppImage plus the .home extension

You would then move the .home folder and the appimage to another computer and by that
get all the data regarding the appimage with you? And updating the appimage to
a new version would also work after moving the appimage to
another computer?

8

Yes and yes.

When you move both the AppImage and its folder to another computer, then the data would travel with it.

When updating the AppImage you might have to rename the directory to match the name of the new AppImage.

9

create a folder next to the AppImage with the exact name of the AppImage plus the .home extension.

If the name of the appimage is Potato_Presenter-v1.0.0-x86_64.AppImage then the name of the
folder should be Potato_Presenter-v1.0.0-x86_64.home?

everything that would normally be saved in $HOME will be saved there instead.

Does that mean the appimage program will leave
no trace on the system? Or
that depends on the appimage program?

10

That simply means that whatever an application would normally save in $HOME will be redirected to the folder next to the AppImage with the exact name of the AppImage plus the .home extension.

If the application writes outside of $HOME, then that will not be redirected.

If you want to leave “no trace”, then a sandbox like Firejail might be interesting for you, because it can restrict what the application inside an AppImage can and cannot do.