FAQ
Frequently Asked Questions & Misc
Last updated
Was this helpful?
Frequently Asked Questions & Misc
Last updated
Was this helpful?
is inspired by the concept of the , but is not an exact replica. While the AUR is a community-driven system where users can freely submit packages by creating repositories and PKGBUILDs with minimal oversight, takes a more controlled approach.
The key distinction is in how packages are added. implements a review system where maintainers must evaluate and approve packages before they can be included in the repository. This extra layer of scrutiny helps maintain higher quality standards and better compared to the AUR's more open submission process.
So while was influenced by the AUR concept, it's not truly an AUR since it prioritizes curated content over unrestricted user submissions.
The AUR isn't inherently a security nightmare if you exercise common sense—like reviewing PKGBUILDs before installation or avoiding outdated packages.
Unlike the AUR, where anyone can upload a package, we require maintainers to manually review, evaluate & locally test all SBUILDSin a sandbox before approving any new submission/PR.
We also go as far as forking any third party repository we use, under the org.
We have a detailed section dedicated to it here:
The majority of our packages (~80%) are built from source.
The largest of the remaining percentage, we fetch from upstream sources like Github Releases.
Whatever remains, here we do indeed pull packages from other distros. But this is done to repackage them as statically-linked or dependency free bundles. We end up rebuilding/patching most of the original source package. We don't violate any Licensing or TOS (because we use the src distribution itself), and we also redistribute the LICENSE file where we are required to do so. This practice of repackaging is similar to & other projects.
The data at is used for comparisons, statistics & to infer popular/trending packages (because soar collects no user metrics).
Currently, our cache is of two types:
We do the following to ensure we guarantee at least some level of portability for each package:
The few who do, either lack the interest, skill or time, or all of these to provide a properly made Portable Package. There are numerous examples, you simply need to see their issues tab & search our usernames.
We fix & patch any & all missing or broken components in any Package we add/build. This means, most soarpkg no longer resemble the "source", wheras AM has a policy that states "it's better to rely on/contribute to upstream, even if upstream has no interest or provides broken packages". You can read, why we disagree: Why not contribute Upstream?
Cache refers to prebuilds provided by pkgforge's CI that soar uses by default. Think of it as the or .
provides prebuilt Static Binaries (): Cache
provides prebuilt GUI Apps (): Cache
is indeed slow, See:
However, we use over other the default musl allocators, and also prefer & , this means the packages we compile from source have identical performance to their GLIBC counterparts, sometimes even faster.
Dependency heavy packages for instance typically involve docker containers, so we mark these kind of SBUILDs with a :
We have written dedicated documentation about each format & their portability, you can find them at
You can also specifically filter & only use portable packages at the expense of size, we add a special if we are confident the package works on Any Linux
Unfortunately, with the , most developers have no interest in AppImages or
So, creating PR that the upstream won't even accept is a huge waste of our time. However, we (mostly ) still try our best to contribute upstream whenever possible.
Soar itself has added appimage.github.io as an external source:
has had no proper spec or validation for packages that people submit, for most of its existent.
It is no longer maintained actively, with hundreds of & s plaguing the project for years.
Most entries are useless:
Most entries contain years out of date packages:
Many entries are missing/non-existent:
seems to be a far better alternative & is actively maintained
We () & are friends.
has added partial support for some of since , thanks to this :
Soar itself has also added AM as an external source:
is a giant beast, & . This makes it very hard, if not impossible, to create CLI/GUI in a real programming language, as there's no programmatic data format like JSON/YAML. Parsing strings from shell scripts is neither safe nor reliable.
prioritizes Security through its implementation in Rust, a memory-safe programming language. We are committed to maintaining rigorous security standards, including comprehensive Build Logs, robust Checksum validation, and secure build and installation Sandboxes. These protective measures are fundamental to our approach and non-negotiable.
A safer, saner, easier & richer alternative to hacky-shell script was created, it's called , You can read about it here: & unless AM ever starts using it, the recipes are entirely incompatible.
The reasons, listed above, make 's & 's philosophy & goals incompatible for a direct collaboration.
: is:public archived:false template:false lang:c lang:crystal lang:go lang:nim lang:rust lang:zig stars:>5 cli OR tool OR utility (Sorted By: Recently Updated)
: is:public archived:false template:false stars:>5 GUI OR Portable OR Package (Sorted By: Recently Updated)
List:
List:
: NOT user:Azathothas NOT user:xplshn NOT user:metis-os NOT user:pkgforge NOT user:pkgforge-community NOT user:pkgforge-dev NOT user:pkgforge-security NOT is:fork pkgforge.dev
||: "*pkgforge.dev" -site:pkgforge.dev -site:ajam.dev
drafted repos & projects which would eventually become , ~ July, 2023, You can read more about it here:
After , was created ~ Sep 25, 2024, You can read more about it here:
We realized it pretty quickly that, wasn't sustainable, and a User Repository consisting of community submitted packages, just like , was desperately needed. Thus, , came into existence