Update install-gnu.md: Added AM AppImage management guide

[davidhedlund]

Good news RetroArch AppImage users! I’ve confirmed that all four AppImages—retroarch, retroarch-qt, retroarch-nightly, and retroarch-qt-nightly—for both x86_64, and x86—are now available through AM, the AppImage package manager.

I reached out to the author of AM and asked them to add these builds, so a big thank you and well‑deserved credit to him for expanding the catalog and making it easier than ever to install, manage, and update RetroArch builds directly from the command line. You can see the details here: ivan-hc/AM#2255, ivan-hc/AM#2293.

Additional info

AM is a relatively obscure tool, perhaps due to the lack of packaged releases, but it remains the most advanced and feature-rich terminal-based AppImage package manager available. Using it eliminates the need for custom scripts to download AppImages, such as nightly builds, by handling everything directly from the command line.

[ivan-hc]

Given the size of the packages, it would be even easier to update them if they were redistributed outside of the 7z archive that contains them, and with the necessary information for delta updates.

I wrote a guide to implement this information and make AppImages faster to update using appimageupdatetool and zsync. It is just 5 minutes reading:

https://github.com/ivan-hc/AppImage-tips

I'm the maintainer of AM. Thanks @davidhedlund for the support.

[davidhedlund]

Given the size of the packages, it would be even easier to update them if they were redistributed outside of the 7z archive that contains them, and with the necessary information for delta updates.

I wrote a guide to implement this information and make AppImages faster to update using appimageupdatetool and zsync. It is just 5 minutes reading:

https://github.com/ivan-hc/AppImage-tips

I'm the maintainer of AM. Thanks @davidhedlund for the support.

Thank you as always — you’re incredibly helpful. I had planned to submit a feature request about zsync for RetroArch next week, but your assistance sped up the process, so I’ve gone ahead and done it now.

• [Feature Request] zsync adoption for AppImage updates RetroArch#18932

See also:

• [Feature Request] Add update feature for the AppImage (GNU/Linux) RetroArch#18924

[davidhedlund]

@ivan-hc If you’re okay with it, could you please leave comments on libretro/RetroArch#18932 and libretro/RetroArch#18924? That way, the RetroArch developers can contact you directly for assistance. Your input would be extremely helpful and would likely make resolving both issues much more feasible.

[ivan-hc]

@ivan-hc If you’re okay with it, could you please leave comments on libretro/RetroArch#18932 and libretro/RetroArch#18924? That way, the RetroArch developers can contact you directly for assistance. Your input would be extremely helpful and would likely make resolving both issues much more feasible.

You can tag me where is needed, I can try to help them, if they ask. I don't like to spam other's work.

Thanks

[davidhedlund]

@ivan-hc If you’re okay with it, could you please leave comments on libretro/RetroArch#18932 and libretro/RetroArch#18924? That way, the RetroArch developers can contact you directly for assistance. Your input would be extremely helpful and would likely make resolving both issues much more feasible.

You can tag me where is needed, I can try to help them, if they ask. I don't like to spam other's work.

Thanks

I understand. In that case, I’d recommend subscribing to the issues if you want to keep track of what’s happening; RetroArch is a very large project.

[ivan-hc]

I understand. In that case, I’d recommend subscribing to the issues if you want to keep track of what’s happening; RetroArch is a very large project.

I'd love to, but I already have my own projects on the go, focused on adoption and the best possible support for AppImages.

In the case of Retroarch, they're already capable of creating an AppImage, but they're distributing it incorrectly: in an archive and without delta updates.

There's not much they need to do to improve what they already have.

I'd just need to look at their CI where they create the AppImage to understand what needs to be changed to fix all the problems.

But there's another issue that leaves me perplexed: the .home directory they package, which contains the dotfiles. Why do they do this? Is it for maintaining portable configurations? They could easily be packaged in the AppImage and called according to their AppRun, via a suitable environment variable.

I need to talk to the maintainer; we'll resolve this issue quickly.

But until then, following all the developments is counterproductive.

In the meantime, you can tag me in messages and tell them to contact me. I'll be happy to help.

I can then focus on other things.

Retroarch is certainly a great project, but it's not something I use, nor do I think I will, given my needs, so I'm not very interested in understanding how it works. I have to be honest. But what really interests me is the AppImage, the mere fact that the package is there. And if it needs improving, I'm here.

See you soon.

[davidhedlund]

Approving it will be very helpful as it shows users how to automatically run the latest Nightly AppImage recommended in the RetroArch bug tracking template. I will not make more commits to it. It is ready to be merged.

@fpscan

[davidhedlund]

@fpscan Thank you for reviewing and merging it. ❤️