search

AppImageCommunity / libappimage

Implements functionality for dealing with AppImage files
https://appimage.org
Other
46 stars 29 forks source link

Will you ever add support for integrating appimages to /usr? #169

Closed gholmann16 closed 2 years ago

gholmann16 commented 2 years ago

I'm trying to write an app that integrates AppImages into the system. I'm wondering why I can't integrate appimages into the /usr folder, and right now I'm using a workaround that allows me to. If you think its a bad idea, can you explain why? From what I can see its not so much of a risk of overwriting/spoofing as other apps because the library decides what to execute and what to call the app.

As for why I want to integrate into the system: if every user has to download their own apps then AppImage loses its ideal to be space efficient unlike flatpaks or snaps. Imagine you share a computer with one or two other people, and you both want to download chrome, spotify, discord, and libreoffice. You are doubling or even tripling your hard drive impact.

TheAssassin commented 2 years ago

I'd like to suggest a workaround/alternative approach. AppImageLauncher supports a /Applications directory which is system-wide. appimagelauncherd automatically finds AppImages there and integrates them for every user. This approach has a few advantages over what you have in mind, but I don't want to discuss this in this issue, since it's off topic.

gholmann16 commented 2 years ago

I assume by advantages you mean the thumbnails that get extracted by libappimage. I wouldn't want to use appimagelauncher's build because it uses a daemon and I think the goal of coding in such a low language as C is so that it will run as fast as possible, and therefore I would not like a background service. I'll try to code this myself and see what happens but I don't see how I'm supposed to make libappimage integrate into all users desktops. Am I supposed to use root to fake the uid of individual desktop users and run it as all existing users?

TheAssassin commented 2 years ago

Ok, since you're asking, I'll respond.

I assume by advantages you mean the thumbnails that get extracted by libappimage.

The runtime itself does some basic thumbnailing, too, but it does it in a user-local way. AppImageLauncher also integrates every AppImage for every user. There is no need for user-global integration IMO. In fact, user-local makes things like AIL's name collision detection significantly easier. Also, some users may want to configure AppImageLauncher differently, and this approach allows AppImageLauncher to behave differently for different users.

Using a global directory but integrating locally makes most sense IMO. I'd follow that approach if I were you. And AppImageLauncher shows it's possible already.

it will run as fast as possible

That's a misconception. Making a request to a daemon to integrate a file is, for instance, not any slower than running the integration directly. The bottleneck is the I/O here... You wouldn't notice a difference even if it was written in Python.

In the long term, AppImageLauncher's UI won't perform the integration directly any more, but will delegate this task to appimagelauncherd if possible to avoid any delays when launching an AppImage.