GithubSoar

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:

GLIBC vs MUSL

MUSL is indeed slow, See:

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.

Portability

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

note:
  - "[DO NOT RUN] (Meant for pkgforge CI Only)"
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?

  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

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

PreviousDifferencesNextInfra

Last updated

Was this helpful?