Soar package manager
9 points by zelda
9 points by zelda
I went down a Linux packaging rabbit hole recently because someone created an issue on my project asking for Appimage support. I already provide a Flatpak so I never really felt the need to also provide Appimages, but I thought, why not?
Hoo boy. Maybe this is a skill issue, but creating an Appimage was going to be massive pain in the A. They are not completely isolated from the host system like you might think. Issues with glibc version right off the bat. Does not play nicely with glib/gtk. Basically, I was going to need to ship super old versions of everything if I had any hope of the Appimage running on distros like Debian. Also something about relying on a version of fuse that most distros don't even ship anymore?
I think Appimages are popular with Electron apps because the only thing that needs to be supported is Electron itself. Similar story with QT apps: QT is a framework, not a GUI toolkit (prove me wrong) so if you can manage to bundle whatever version of QT you need you're relatively isolated already and good to go.
"Static binaries" sounds really attractive. But sometimes you need things like config files, .desktop entries, icons... But that's solvable right? Maybe put them in some kind of archive, maybe with a manifest, you could even lay out the folder structure to mirror the filesystem locations each file will be installed to. Congratulations you just re-invented the .deb
I ship Flatpaks but honestly I've gone back to installing everything I can using pacman. Because guess what Arch packages are? They are binaries. Binaries with the occasional metadata, and a mature, battle tested tool that manages them. Sounds great to me!
How does this compare to Nix, Pacman, or some others?
It's pretty much right on their front page:
Install static binaries, AppImages, and portable packages across any distro. No root required.
It sounds kind of similar to using NPM to install a binary to ~/.npm-global/bin, or pip to install to ~/.local/bin, but for packages in general instead of being intended for a specific language. So very different from Pacman, which is a traditional system package manager.
Don't know enough about Nix to make a comparison.
It's pretty much right on their front page: Install static binaries, AppImages, and portable packages across any distro. No root required.
Alright, thanks. Didn't know pacman can't do those things. Somehow I had assumed it can do those.
I use Nix for pretty much for everything on my work Fedora PC and personal NixOS laptop.
I think this is similar to my own "package manager". It's more like a binary downloader. On one hand, my package manager can only install single-file binaries- Soar seems to have an approach for that?
But I think my approach of having scripts that download the binaries is more flexible- their approach seems to require them to repackage stuff?
(My package manager is very primitive and lacks a ton of features- plus it's like unsafe to use. Not recommended, but it's been handy to me already.)
To me the main problem with the mainstream packaging ecosystems is their dependence on GPG. That automatically makes them 10x harder than they need to be. The arcane formats and tooling are a close second, but to be honest I'd be willing to rock with all of that if I didn't need to maintain a damn GPG key. I'll never do it.
So kudos if this Soar system is bypassing that.