Splux Linux

Contributing to sps-community

One package per pull request. The pull request is not merged until the recipe indexes, the sources hash, and someone has actually built it.

Before you open a PR

1. Confirm the name is not already in

sps-core or sps-extra. Search https://splux.robertflexx.dev/packages/ as well.

1. Read the SPS package maintainer guide.
2. Put the recipe in category/name/recipe. Create the category directory

only for this package.

1. Use a canonical upstream tarball or zip, HTTPS, with hash sha256: and

exactly 64 hex digits. Download it yourself and hash it. Do not copy a digest from a web page you did not verify.

1. Declare every library and tool the build needs. Isolated builds install

only depend and builddep. If configure auto-detects a library, name it and fail the build when that feature is missing.

1. Shared libraries go in lib64 on this architecture

(--libdir=/usr/lib64 or Meson --libdir=lib64).

1. Build it:

cd category/name
mkpkg

1. Install into a disposable root, run pkcheck and a smoke test, then

pkdel. Do not open a PR for a recipe that has never been compiled.

What the bots check

GitHub Actions runs src update with core (100), extra (80), and this tree (50). That catches unknown recipe keys, bad hashes, dependency cycles, and package names that collide with core or extra. It does not compile upstream software. A green check is necessary, not sufficient.

Commit messages

Use a package-specific subject, for example ripgrep: add 15.0.0.

After merge

Users who enabled community run src update and can sget install the package. Official Splux installs do not see it until they add the git line themselves.