Just a thought: AppImages on demand?

I had an idea I wanted to float out there… what if there was a FOSS server solution anyone could host which on demand would produce an AppImage of any software from any repo (via dnf, apt, ect) requested via a REST API? Off the top of my head maybe it could be done using chroots but i’m sure there’s a more elegant solution.

The source packages on the server would be kept updated with a new AppImage produced whenever there’s a change.

The server would hold the AppImages and their source packages for 14 days but keep resetting that timer whenever it’s queried for an update so storage space is only consumed if a machine is actively seeking updates for that AppImage.

On the client-side there’d be a CLI script for managing your AppImages and an update daemon that checks the server for changes.

It’d be sort of like an appimagehub in a box that anyone could run but it’s AppImages would be packaged straight from distro repos with the latest updates.

What am I missing?

1 Like

Interesting topic.

I think for security purposes, you would have to keep the appimage, even after 14 days. If not, how would clients receive updates? How would the server know that there was an update?

I like the hub idea. Similar to dockerhub, but even with dockerhub, there is no security outside of using only officially supported images.

The biggest issue I see is that you how would you account for all the differences in the various distros? Each distro has the simple task of only packaging for it’s distro, that it knows and understands. I would think that there would be a lot of difficult coding to account for every different distro out there and how they work differently, ie different ENV vars, different paths, etc.

Still, an interesting idea. By using a REST API, you could deploy this as a web service.

Thinking about it… it doesn’t need to be a server, that’s more of a bonus step. There’s no reason it couldn’t run locally and a user could just sync the AppImages to other devices.

The idea was that once an AppImage is requested the source packages are downloaded and an AppImage is created from those. As long as the user checks for an update once every 2 weeks (it should be multiple times a day) that AppImage will always be available. If the server doesn’t see a user attempt an update it’ll assume the user has deleted it and will delete it’s own storage but if it’s requested again it’ll just start from step 1 so there’s no scenario where an update can fail.

As for the server knowing there’s an update, it’d just maintain a bi-daily update schedule for all it’s AppImage sources. If there’s a change it creates a new AppImage and increments a number somewhere so client’s know to update.

AppImages solve a lot of that because their binaries are self-contained though you’re right, they do plenty of reaching outside depending on what they’re designed to do.

freedesktop.org has ENV variable standards though I don’t know to what degree they’re obeyed (I think most distros/DEs do). AppImages have an initialization script so a generic shim could be added that normalizes ENV variables for supported distros within the scope of the launching app.

If the binaries are using hardcoded paths that’s trickier.

Keep in mind that the biggest failure will be the human element. Some level of notification that an update is available needs to be part of the process. Some users (non-technical) aren’t going to remember to check for updates.

As for “reaching outside”, hash numbers can be used to ensure integrity (don’t forget the Security CIA triangle).

Looking good otherwise. However, you can expect a certain amount of push-back as part of the app-image - flatpak - snap package wars of past, but I like where you’re going with this.

1 Like

Can’t the open build service be used for most of this?

https://openbuildservice.org/

Here’s a forum thread of people talking about automatic Appimage creation from RPMs using OBS.

1 Like

That’s a case of me projecting myself onto the user because i’d be running updates automatically. Good example of the human factor.

What a link! That’s getting saved. I think it’s best summarized with this statement:

“Open Build Service: Building a package from it’s sources for multiple distributions and downloading it.”

That looks like an excellent way to get packages for your distro as an alternative to AppImages though some people may still want it in an AppImage.

Where this might differ is it looks like you have to provide the source code which is in a different location for every project and I don’t know if OBS can “notice” when there’s a new release so a per-project script would need to check for changes.

1 Like

OBS is self hostable or there is a public instance that is used to build openSUSE and presumably whatever else you want it to. I’m not hugely knowledgeable about it besides what the home page says about it.

This sounds a bit like Flatbot for packaging Flatpaks…

1 Like