sps-core
Official base recipe collection.
sps-core · log · files · refs · tags · releases · people · languages · GitHub
Showing newer commits from GitHub.
efb6dba (main)git clone https://github.com/RobertFlexx/sps-core.gitLanguages
People
Recent commits
README.md
SPS core package collection
This repository is the official base recipe tree for SPS Linux (informally Splux): bootstrap toolchain, libraries, utilities, boot and device infrastructure, networking, and SPS itself. It contains recipes and small supporting files, not source archives or binary packages.
SPS the package system is separate from the distro. These recipes are ordinary SPS recipes, so a Linux From Scratch tree (or any other SPS root) can consume them. The linux-desktop and linux-custom kernels, and anything setup does with hostname, fstab, and init, are SPS Linux defaults. An LFS build using SPS does not have to follow that installer.
Package categories are organizational. A package's name record is its identity; the category is not part of the name. Core uses these categories as packages are added:
base/ boot/ devel/ fs/ kernel/ lang/ libs/ meta/ net/Category directories are created only when they contain a package.
Configuration
The normal official configuration is:
git core https://github.com/RobertFlexx/sps-core.git 100src update clones it to /usr/src/sps/core by default and builds the local package index. The checkout remains an ordinary Git repository.
src update
src status
src search bash
src show bashAn administrator can put overrides in a higher-priority directory repository:
dir local /usr/local/src/sps-local 200
git core https://github.com/RobertFlexx/sps-core.git 100src which PACKAGE shows the selected definition and alternatives.
Building a package
Enter the package directory and run mkpkg:
cd /usr/src/sps/core/libs/zlib
mkpkgInspect the archive, install it into a disposable SPS root, run pkcheck and pkstat, perform an appropriate smoke test, then remove it with pkdel. The exact recipe format and verification procedure are documented in the SPS package maintainer guide.
Contributions
Base changes must keep main indexable and buildable. Use canonical stable upstream archives, exact SHA-256 hashes, reviewed dependencies, and short recipes using the upstream build system. Do not commit downloads, package archives, or build logs. A package is ready for main only after its source, build, staged files, install, checks, smoke test, and removal have been reviewed. Work that has not passed those checks belongs on a testing branch.
Update one package in place and commit it with a package-specific message, for example zlib: update to 1.3.2.
Software that is not ready for extra belongs in sps-community. That collection is opt-in and is not enabled by setup or mkiso.