Integrated AppImages in my ISO

[delinuxco]

Greetings all, I have recently releases a new version of DeLinuxCo Manjaro Spin but with a twist. I have included 6 applications as AppImages.

These AppImages are fully integrated into the system, menu and all. It is my belief that AppImages should be part of the distro repo system for a couple of reasons. Mainly, the ability to install packages during the building/releasing of an ISO.

I started a thread on the Manjaro Forums, here: https://forum.manjaro.org/t/new-delinuxco-cinnamon-iso-with-pre-installed-appimages/166841
But I have not had much feedback, normally I get hammered :-)

Without reposting the whole thing here again, I would like your thoughts on delivering AppImages via the repos?

I am thinking of sharing the build files to see if anyone would be interested and if anyone with Debian and RPM packages knowledge would be interested in helping out with the code to do so on same said package formats?

-John

[Samueru-sama]

Without reposting the whole thing here again, I would like your thoughts on delivering AppImages via the repos?

Nothing wrong with that, it is common to see appimages in the aur for example.

I think applications like libreoffice are best delivered as an appimage as well.

[probonopd]

Hi @delinuxco, welcome.

I have recently releases a new version of DeLinuxCo Manjaro Spin but with a twist. I have included 6 applications as AppImages.

AppImage is an easy way to add specific application to Live ISOs. And AppImages are especially suitable for users running Live ISOs, e.g., in case users want to download a newer version than what comes with the Live ISO.

It is my belief that AppImages should be part of the distro repo system

Well. The AppImage format has been designed specifically so that no package manager, no repositories, and no special tools are needed, and there are no dependencies other than what comes with most distributions by default. Sure, you can manage AppImages with a package manager, but then you are losing the main advantages that the format was designed for. It's like trying to (ab-)use a sports car to do the job of a truck. Sure, maybe it can do it. But it's not designed for it.

There are some downsides of managing AppImages with distribution package managers:

• If your users move an AppImage to another drive or path, then the distribution package manager will not know how to handle this situation
• If your users update an AppImage using AppImageUpdate, then then distribution package manager will not know about it
• If your users want to move or delete an AppImage managed by a distribution package manager, they most likely need to be root (something AppImage explicitly was designed to avoid)

[delinuxco]

Hi @probonopd thank you for your input, here is my thoughts on your points.

If your users move an AppImage to another drive or path, then the distribution package manager will not know how to handle this situation

Well using the distribution manager, the user would not have access to easily moving the AppImage because they are stored in /opt/appimage/

If your users update an AppImage using AppImageUpdate, then then distribution package manager will not know about it

Well, all updating would be handled by the package manager like any other. To the average user, they would know know or care, as long as the application works as intended.

If your users want to move or delete an AppImage managed by a distribution package manager, they most likely need to be root (something AppImage explicitly was designed to avoid)

Removing the AppImage would be like any other package. And just for the record, AppImage was not designed explicitly to avoid needing to use root privileges.
The fact that an AppImage can be run without root privileges is a feature, but I have consulted with AppImage here on Github and there is nothing preventing an AppImage from being executed from /opt

[probonopd]

Well using the distribution manager, the user would not have access to easily moving the AppImage

...hence diluting its characteristics

Well, all updating would be handled by the package manager like any other.

Again, diluting the value of AppImage where the user chooses when to update what, and gets to keep the previous version in case the new one doesn't work properly.

Removing the AppImage would be like any other package.

AppImages are removed by putting them into the Trash. An AppImage is not a package.

And just for the record, AppImage was not designed explicitly to avoid needing to use root privileges.

It was. Trust me. I developed it.

there is nothing preventing an AppImage from being executed from /opt

Correct. You can do what you intend. All I am saying is that essentially you are downgrading many of the features I have designed into the AppImage file format to essentially be no better than normal packages. Many of the specific benefits of the AppImage file format are not going to work if you do that. But it's your choice.

I am just explaining this so that you (and others reading this) might understand what the AppImage file format was designed to do, and understand that putting AppImages into packages, while possible, removes some of its desirable characteristics. In fact, if one likes how packages work, why not just use packages. AppImage was made because I was dissatisfied with how packages work.

[delinuxco]

It was. Trust me. I developed it.

Then my mistake, my apologies.

I am just explaining this so that you (and others reading this) might understand what the AppImage file format was designed to do, and understand that putting AppImages into packages, while possible, removes some of its desirable characteristics. In fact, if one likes how packages work, why not just use packages. AppImage was made because I was dissatisfied with how packages work.

Allow me to explain why I think AppImages are such a great tool and how I came to use them.
It started with using the application Cinelerra-GG on Arch based Linux, and I wanted to include it in my ISO build. The application is a complex one, with many dependencies, and it was starting to be difficult to build the application because there is a release about every six months, OK, I will be honest, it was a dependency nightmare.

Switching to AppImage just seemed to work perfectly, I decided to try building the a package to deliver the AppImage using the repo that I created for my little niche Manjaro spin. It worked fantastic, even in the live ISO, the application running as an appimage performed just as expected.

That is when I noticed that many developers were offering AppImages for their packages, I even took over kdenlive-appimage from the AUR.

The beauty of the AppImage, as I see it is this;

1. It has the ability to nearly eliminate dependency issues.
2. It can be delivered through the already existing repo system.
3. With the package available in the repo, it can be added to the list of applications to be installed during the ISO build, it just pulls it from the repo like any other package.
4. The package contains the *.desktop file and icon for proper system integration.
5. Users can try out another version of the package for testing or what ever, just by downloading directly and trying it out while the installed AppImage/Package is not running.
6. Removal of the AppImage is simple and clean.

This is why I have become somewhat of an apologist for AppImages, and that says a lot, because I have pretty much always considered my self package format agnostic.

I have a git lab page started, I am planning on posting the code used to build the packages and review and hopefully improve it.

Once again, my sincere apologies for not properly understanding the real purpose of the origin of the AppImage, it was not to offend.

-John

[probonopd]

No need to apologize, if you see value in what you are doing, then by all means keep doing it. I just wanted to point out that everything is a tradeoff.