Splux Linux

source-based Linux using SPS

sps-core


Official base recipe collection.

sps-core · log · files · refs · tags · releases · people · languages · GitHub

HEADefb6dba (main)
Commits31
Files157
Tags0
Releases0
Latestnone
Clonegit clone https://github.com/RobertFlexx/sps-core.git

Languages

People

All contributors

Recent commits

CommitSubjectAuthorWhen
efb6dbalang/perl: move perl into coreDistroDeveloper
94b7436libs/acl, libs/attr: fetch over httpsDistroDeveloper
d72a194README: document the opt-in sps-community collectionDistroDeveloper
55a5f5bDeclare Python's compression libraries and ship a shared libbz2 in lib64.DistroDeveloper
d8b571aInstall CPython modules under lib64 so relocated python works.DistroDeveloper
d8ceeb2Ship init scripts for every PID 1 with core daemons.DistroDeveloper
bfa89f1Drop OpenSSL 4, fail Python builds that lose _ssl, and add toolchain extras.DistroDeveloper
aac95eaInstall sqlite and python's other libraries into lib64.DistroDeveloper
82b9952openssl: skip docs and install shared libraries into lib64.DistroDeveloper
9ce60aflibxml2: treat python as a meson feature and install libs in lib64.DistroDeveloper
55125c3core: ship dbus, sshd, and dhcpcd units for both initsDistroDeveloper
8f85ba9filesystem: leave os-release to the distro packageDistroDeveloper
57cc657core: add Splux desktop kernels; leave udev to the init choiceDistroDeveloper
bf457d8core: add PAM, shadow, tzdata, and a bootable userlandDistroDeveloper
37bfffbreadline: ship a shared library and link bash and less against itDistroDeveloper
7f6949fcore: add unzip, zip, parser tools, sqlite, pcre2, GnuPG, and OpenSSHDistroDeveloper
8812f9flibs: build ncurses with wide character supportDistroDeveloper
74b9a1acore: add base utilities, libraries, and gitDistroDeveloper
cd81fd6net: add network and TLS toolingDistroDeveloper
5c5a431libs: add ncursesDistroDeveloper

Full log

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 100

src 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 bash

An 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 100

src 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
mkpkg

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