FAQ

Frequently Asked Questions & Misc

Is this really an AUR?

1. Soarpkgs is inspired by the concept of the AUR, 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, Soarpkgs takes a more controlled approach.

2. The key distinction is in how packages are added. Soarpkgs 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 security compared to the AUR's more open submission process.

3. So while Soarpkgs was influenced by the AUR concept, it's not truly an AUR since it prioritizes curated content over unrestricted user submissions.

---

What makes Soarpkgs trustworthy if the AUR is viewed as a security risk?

1. The AUR isn't inherently a security nightmare if you exercise common sense—like reviewing PKGBUILDs before installation or avoiding outdated packages.

2. 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.

3. We also go as far as forking any third party repository we use, under the pkgforge-community org.

4. We have a detailed section dedicated to it here: https://docs.pkgforge.dev/repositories/soarpkgs/security

---

Do you steal packages from other distros & call them as your own?

1. The majority of our packages (~80%) are built from source.

2. The largest of the remaining percentage, we fetch from upstream sources like Github Releases.

3. 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 pkg2appimage & other projects.

4. The data at https://github.com/pkgforge/metadata/tree/main/misc/data is used for comparisons, statistics & to infer popular/trending packages (because soar collects no user metrics).

---

Cache

Cache refers to prebuilds provided by pkgforge's CI that soar uses by default. Think of it as the Chaotic AUR or Homebrew's bottles.

Currently, our cache is of two types:

• Bincache provides prebuilt Static Binaries (soarpkgs/binaries): Cache

• Pkgcache provides prebuilt GUI Apps (soarpkgs/packages): Cache

---

GLIBC vs MUSL

MUSL is indeed slow, See:

• https://edu.chainguard.dev/chainguard/chainguard-images/about/images-compiled-programs/glibc-vs-musl

• https://martinheinz.dev/blog/92

• https://andygrove.io/2020/05/why-musl-extremely-slow/

• http://www.etalabs.net/compare_libcs.html

However, we use mimalloc over other the default musl allocators, and also prefer LTO & PIE , this means the packages we compile from source have identical performance to their GLIBC counterparts, sometimes even faster.

• https://www.linkedin.com/pulse/linux-testing-alternative-c-memory-allocators-emerson-gomes/

• https://www.linkedin.com/pulse/testing-alternative-c-memory-allocators-pt-2-musl-mystery-gomes/

---

Portability

We do the following to ensure we guarantee at least some level of portability for each package:

• We provide prebuilt packages as Cache ,so users don't have to build packages themselves. This avoids users having to install some common dependencies to build a package.

• Dependency heavy packages for instance typically involve docker containers, so we mark these kind of SBUILDs with a note:

note:
  - "[DO NOT RUN] (Meant for pkgforge CI Only)"

• We have written dedicated documentation about each format & their portability, you can find them at ${format}/portability

• You can also specifically filter & only use portable packages at the expense of size, we add a special note if we are confident the package works on Any Linux

note:
  - "[PORTABLE] (#some comments)"

---

Why not contribute Upstream?

1. Unfortunately, with the mass adoption of Flatpaks, most developers have no interest in AppImages or other formats

2. 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.

3. So, creating PR that the upstream won't even accept is a huge waste of our time. However, we (mostly @Samueru-sama) still try our best to contribute upstream whenever possible.

---

Why not contribute to appimage.github.io?

Soar itself has added appimage.github.io as an external source: https://docs.pkgforge.dev/repositories/external/appimage.github.io

1. appimage.github.io has had no proper spec or validation for packages that people submit, for most of its existent.

2. It is no longer maintained actively, with hundreds of Issues & PRs plaguing the project for years.

3. Most entries are useless: https://github.com/AppImage/appimage.github.io/issues/2909

4. Most entries contain years out of date packages: https://github.com/AppImage/appimage.github.io/issues/1297

5. Many entries are missing/non-existent: https://github.com/AppImage/appimage.github.io/issues/2356

6. AM seems to be a far better alternative & is actively maintained

---

Why not contribute & collaborate with AM?

• We (@pkgforge) & AM's Author are friends.

• AM has added partial support for some of PkgForge's Reposotories since Nov 10, 2024, thanks to this Issue: https://github.com/ivan-hc/AM/issues/1079

• Soar itself has also added AM as an external source: https://docs.pkgforge.dev/repositories/external/am

• So everything listed below is meant for a technical comparision & NOT to harass/insult either side. So please be decent & don't misquote us.

1. AM 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.

2. 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?

3. Soar 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.

4. A safer, saner, easier & richer alternative to hacky-shell script was created, it's called SBUILD, You can read about it here: https://docs.pkgforge.dev/sbuild/introduction & unless AM ever starts using it, the recipes are entirely incompatible.

5. The reasons, listed above, make PkgForge's & AM's philosophy & goals incompatible for a direct collaboration.

---

Public Tools Search

• Search Awesome CLI: 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)

• Search Awesome GUI: is:public archived:false template:false stars:>5 GUI OR Portable OR Package (Sorted By: Recently Updated)

• List: https://github.com/stars/Azathothas/lists/soarpkgs-packages-tba

• List: https://github.com/stars/Azathothas/lists/soarpkgs-binaries-tba

---

Public Code Search

• GitHub Search: 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

• Google|Bing|Baidu: "*pkgforge.dev" -site:pkgforge.dev -site:ajam.dev

---

History & Lore

• @Azathothas drafted repos & projects which would eventually become Toolpacks, ~ July, 2023, You can read more about it here: https://docs.pkgforge.dev/repositories/bincache/faq#history-and-lore

• After Azathothas/Toolpacks#28, PkgCache was created ~ Sep 25, 2024, You can read more about it here: https://docs.pkgforge.dev/repositories/pkgcache/faq#history-and-lore

• We realized it pretty quickly that, PkgCache wasn't sustainable, and a User Repository consisting of community submitted packages, just like ivan-hc/AM, was desperately needed. Thus, Soarpkgs, came into existence ~ Nov 04, 2024