Arch-Deployer VS org.qbittorrent.qBittorrent

Arch2AppImage is useless, just like my Arch-Deployer (Arch2AppImage is inspired by my project, see it's README), I've also created an "issue" on its repository to explain why I've abandoned it, see https://github.com/hanzala123/arch2appimage/issues/25 ).

Hi everybody, I'm the developer of Arch-Deployer and AM Application Manager

I have posted previously that it's possible to go from AUR source ->AppImage -> Firejail with a script like Arch-Deployer for the basis of a secure OS.

Hi, I'm the developer of Arch-Deployer, a script to bulk download Arch Linux packages from the main repositories (and from Chaotic-AUR) with all their dependences to finally compile AppDirs to study (the AppRun script and other internal components) before their exportation in AppImage packages. When I created it, my goal was to create AppImages to upload on my other repository named AM Application Manager, to made all these programs available for all the others GNU/Linux distributions. But I had not taken care of a particular issue: GLIBC compatibility!

If I have time enough, I wanna try to create a script that automatizes all the processes, also for you developers, but my knowledge is limited to the download of packages from Debian and derivatives or from Arch Linux to create these structures, I'm not much good in compiling these programs by myself into a chroot, I'm just an enthusiast.

I have not added support for Chaotic-AUR, you can consult this issue to check the reason. You will most likely need another script to export your programs to the AUR to make them executable on any other distribution (I've already done this for some programs in my other project, "AM", the Application Manager).

https://github.com/ivan-hc/Arch-Deployer I hope you like it.

In my experience with Flatpak, when upgrading a runtime (from Nvidia) to the next version, used by the same app (WINE), I ended up with two runtimes and not even the "uninstall –unused" option had removed it , I did it manually later (and it's not very intuitive). Also, aside from "du", most disk space measurement tools still identify an inordinate amount of space, and even if you show me that article (which is one of many I've already read about it) this does not changes my experience with this format, because "ostree" is not a very intuitive system even for those who, like me, are used to LSB (Linus Standard Base) standards. I had to intervene on a malfunction of a single app I wouldn't be able to make my changes, while on a regular package it is still possible to do it... and for AppImages it is even more so. I once reported a problem to qBittorrent maintainers on flathub (this), never got a response. On the contrary, movements on the repository have made them (I'm telling you about when qBittorrent was switching from qt5 to qt6), and it was correcting their file and then returning it to the previous version. I don't know how apps work on runtimes, but this attitude (which I've seen in real time) seemed to me to be that of people who didn't even know what they were doing. With AppImage at least I have the security of knowing what's inside. Taking OBS again as an example, in the past whoever built this app in AppImages obtained packages ranging from 70 to 150 MB of space (always compressed), while I use other systems to package my AppImages at most and managed to bring it to 250 MB with deb packages (and it still doesn't work, some environment variables that I didn't include in the AppRun... you can see it here), not to mention the fact that many developer's platforms cut out the workspaces that we used to build on (i.e., for backwards compatibility issues we use usually the oldest Ubuntu LTS release still supported). I'm trying to go differently than the AppImage constructors of the past, and this method looks promising.