Debian/Ubuntu packaging request for the AM team

[davidhedlund]

Is your feature request related to a problem? Please describe.

An APT‑integrated AppImage package manager is notably absent from the free‑software ecosystem, which presents a significant problem. AppImages, like Flatpak applications, are designed to be distribution‑agnostic and compatible across most GNU/Linux systems; however, unlike Flatpak—which has gained substantial popularity and offers robust management tools—AppImage lacks any comparable package management infrastructure. This leads people to rely on outdated AppImages; not all AppImages are self‑updating or support mechanisms like zsync, so users are forced to manually download new versions, which is inconvenient and error‑prone.

This makes AM an ideal candidate to fill this gap and offer a proper, maintainable, system‑wide AppImage management solution through the standard APT ecosystem. Currently, AM remains relatively obscure, perhaps in part because it is not integrated into any official packaging infrastructure; unlike most Linux tools, it still requires a custom installation process rather than installation via the distribution’s package manager. If AM were officially packaged, it would become much more convenient to install and maintain, which would likely encourage wider adoption. Even though the one‑liner for installation is clearly listed on the AM page on GitHub, it is mentally distracting for users to remember that AM is an exception that must be installed outside the usual apt workflow. This friction may cause people to overlook AM over time or simply forget about it, especially when many other tools are only one apt install away.

According to my research, AM is also the most powerful AppImage package manager available, further strengthening the case for its inclusion as an officially packaged APT component. AM deserves significantly more attention than it currently receives.

Additional consideration

As far as I know, very few APT packages are written purely in Bash but it is possible (ble.sh is an example).

Most serious APT packages are implemented in compiled languages for performance and reliability, so in the long term you may want to consider gradually translating AM into such a language if you are interested in packaging it. I respect that you are writing AM for fun, and these days it is not necessary to master new languages from scratch; instead, you can use LLM chatbots to interpret the design and behavior of AM and translate them into a fully functional, compiled implementation written in C, Common Lisp, or a similar language, preserving its flexibility while gaining robustness and distribution‑friendly packaging.

I personally have no expectations and think you should do whatever you like, and I’m very grateful for the current version of AM; this package request simply reflects my role as a long-term lead maintainer of the Free Software Directory, which led me to notice that an APT‑based AppImage package manager is missing from the free‑software ecosystem.

[ivan-hc]

Hi @davidhedlund

my project already have instructions on how to package AM

https://github.com/ivan-hc/AM?tab=readme-ov-file#instructions-for-linux-distro-maintainers

Gidro-OS by @fiftydinar (based on Fedora Atomic) is a clear example.

About programming language, I don't have other knowledge except shell/bash. Me and my friend are also trying to made the project as much POSIX as possible, but there are still too many stuff that are bash-only. So it is still a long way.

And yes, it is correct. My project is for fun. I don't even consider myself a real developer after all. I have no study nor experience in the IT. My job was not even related to this. And since I'm unemployed, I have (too much) time to (waste and) improve AM the way I know better.

However, none prevents you to fork AM and convert it to a more reliable programming language.

I close this, but you can keep write here, for any other doubt.

[vishnu350]

... so in the long term you may want to consider gradually translating AM into such a language if you are interested in packaging it.

I am somewhat comfortable with several different programming languages.

My personal opinion is that AM is the one instance where BASH actually shines as the best language for the job. I couldn't believe it at first but have now come to accept it.

BASH is an underrated powerful scripting language that was actually made for programs like AM to be used in system administration. It has immediate access to the most robust and proven system tools (eg. wget, coreutils, grep, etc), all of which are already written in C/C++ and perform very well in your given system.

... you can use LLM chatbots to interpret the design and behavior of AM and translate them into a fully functional, compiled implementation written in C, Common Lisp, or a similar language, preserving its flexibility while gaining robustness and distribution‑friendly packaging.

Switching from BASH to something like C/C++ will surely promise improved performance. But is it worth it just for that extra ~0.5s performance improvement, for an app we call for updates once a week in the background?

You will also need to re-implement complex tools like wget/coreutils/grep/etc. Initially, it will be far from robust and the performance might actually be worse. This is because the code has to outperform solid GNU tools like wget or grep.

Also, APP-MANAGER (the main AM script) is only about 2k lines long, making it very easy to audit and maintain by the community, and basically just sucks less. On the other hand, a C/C++ equivalent program will not be as concise, and may possibly exceed 100k lines if vibe coded.

[davidhedlund]

my project already have instructions on how to package AM

https://github.com/ivan-hc/AM?tab=readme-ov-file#instructions-for-linux-distro-maintainers

Gidro-OS by @fiftydinar (based on Fedora Atomic) is a clear example.

It’s interesting that it has been packaged; this is the first AppImage package manager I’ve seen available as a distribution package, which gives a strong impression of how sophisticated your software is.

Me and my friend are also trying to made the project as much POSIX as possible

It is great that you are trying to keep it as standardized as possible.

However, none prevents you to fork AM and convert it to a more reliable programming language.

Thank you. Right now I’m helping to promote AM by documenting how to use it:

• PPSSPP: Update how-to-update.md: Document how to manage AppImages with AM hrydgard/ppsspp-site#128, Update how-to-update.md hrydgard/ppsspp-site#130
• Retroarch: Update install-gnu.md: Added AM AppImage management guide libretro/docs#1135
• More to come 😀

I close this, but you can keep write here, for any other doubt.

It is common for issues to be closed as “Close as completed”. Please reopen it and instead close it as “Closed as not planned,” so that people who see the title in the tracker understand that the request is not planned rather than completed.

[ivan-hc]

It is common for issues to be closed as “Close as completed”. Please reopen it and instead close it as “Closed as not planned,” so that people who see the title in the tracker understand that the request is not planned rather than completed.

It is not "not planned". I gave instructions to packagers on how to distribute it.

It is a welcome feature instead.

But if your request is to add a .deb or .rpm package myself, yes, it is not planned.

I always say that packager and developer are not always the same person, and are not the same thing at all:

• to develop is the art of writing the code
• to package is the art of exporting already developed software

To built unofficial packages is normal in Linux. Also Linux distributions have many unofficial packages, built on top of build instructions provided by upstream developers. Someone could take care of all of them, but the more only provide the code.

See Bottles, time ago it was distributed as deb, rpm and AppImage as well as Flatpak. Now it is Flatpak only, because Fedora was shipping a broken rpm in their repositories. Due to this, they received tons of bug reports, so they decided to drop support for packages alternative to Flatpak.

That said, I provide the code, but any packager can bundle AM, by following the instructions.

Someone has bundled AppMan (AM in portable mode) as AppImage. It is unofficial and I don't provide it or this as an AppImage because updates in real time are better handled via script. AM/AppMan itself is a scripts system.

[davidhedlund]

But if your request is to add a .deb or .rpm package myself, yes, it is not planned.

Correct, this issue (#2268) is not planned, but the problem is that it is "Closed" instead of closed as "Not planned", hence the request.

See this issue #2007 as an example issue that you closed as "not planned" if you are unsure what I mean.

[ivan-hc]

OK, I'll follow your suggestion. Thanks @davidhedlund

[davidhedlund]

OK, I'll follow your suggestion. Thanks @davidhedlund

Thanks.

[davidhedlund]

@vishnu350 Thank you for contributing to this project; I truly appreciate it. Much of what you’re saying makes a lot of sense. I’m not very familiar with programming languages myself, but I trust your judgment that Bash has its place for AM. If it didn’t, more people would probably have opened issues suggesting you convert AM from Bash to C, for example.

[davidhedlund]

@ivan-hc I updated the title to include “for the AM team” to clarify that the issue is marked as “Not planned” because you don’t intend to handle it yourself. This helps prevent confusion and makes it clear that the instructions for Linux distro maintainers (that you gave me earlier) are still valid and not what’s marked as “Not planned.”

[ivan-hc]

I often get contacted about issues that have already been covered, apps to add but that already are added, and existing options and features. I'm pretty sure someone will ask again in the future. xD