Installs only what it has checked. Removes only what it installed.

AROS software lives in AROS Archives: 1,895 uploads with no dependency data and no install rules. arospkg doesn't copy any of it. It publishes a small index that points at each archive where it already lives and records the size and SHA-256 the download has to match.

The index is public, at github.com/tomaszstaniak/arospkg-index. It holds metadata and nothing else. Before a package goes in, its archive has been downloaded, hashed and opened, and the index only lists what the client can actually handle.

pkg update
fetching https://raw.githubusercontent.com/tomaszstaniak/arospkg-index/main/index.json
index updated: SYS:Packages/db/index.json

pkg search zaphod
zaphod               1.3        x86_64    A simple binary file editor

pkg install zaphod
fetching https://archives.arosworld.org/share/development/edit/zaphod-v1.3-.x86_64-aros-v11.zip
  redirect -> https://arosarchives.os4depot.net/download.php?file=development/edit/zaphod-v1.3-.x86_64-aros-v11.zip
verified and cached SYS:Packages/cache/zaphod.zip
installed zaphod

pkg list
zaphod

pkg remove zaphod
removed zaphod

Proposal — not yet implemented or adopted

Authors describe how their software should be installed, so users and package maintainers don't have to rediscover it.

For the packages in the index, working out what they install and what they need meant downloading each archive, hashing it and opening it by hand. Of an ordinary four-package sample, half couldn't be approved at all: one was a developer SDK the manifest format can't describe, and one needed libraries that no package anywhere can supply, because they belong to the distribution rather than to any package. That second one was a gap in our own format, not in the archive, and closing it is where the check for what a machine already provides came from.

What a manifest would look like

exampleapp below is invented, so that no real program has dependencies or sources attributed to it that it doesn't have. The syntax is proposed. pkg doesn't read this file today.

# exampleapp.toml — an INVENTED package, shown to give the shape.
# Proposed syntax. pkg does not read this file today.

manifest = 1                       # the standard's version, not the program's

[package]
id       = "exampleapp"            # stable, lowercase, never carries a version
name     = "ExampleApp"            # what a person calls it
summary  = "An invented program, used here to show the manifest"
category = "utility/misc"
version  = "2.4.1"                 # upstream's version
revision = 3                       # OUR packaging; bumped when upstream did not change
license  = "GPL-2.0-or-later"

[build]
arch = "x86_64"
abi  = "v11"                       # v1 = mainline, v11 = current distributions

# Other packages. The index must contain them or this package is not published.
depends = ["examplelib"]

# What the MACHINE must already provide. A different question with a different
# answer: no package can supply these.
[[requires_system]]
type = "library"
id   = "SDL.library"

[[requires_system]]
type        = "library"
id          = "crt.library"
min_version = 5

[install]
dir  = "SYS:Packages/exampleapp"   # everything the package owns lives here
icon = "ExampleApp.info"           # the drawer icon, which sits beside the drawer

# Told apart so removal and upgrade know what they may touch.
[[files]]
path = "ExampleApp"
kind = "program"                   # replaced on upgrade

[[files]]
path = "ExampleApp.prefs"
kind = "config"                    # written once; yours afterwards

[[files]]
path = "saves/"
kind = "userdata"                  # the package never owns what appears here

[source]
repo      = "https://example.invalid/exampleapp.git"
revision  = "9f2c1ab4e7d05c38b1f6a0d9e4c7b2a8f1d3e6c0"
# or, for a tarball rather than a repository:
#   archive        = "https://example.invalid/exampleapp-2.4.1.tar.gz"
#   archive_sha256 = "…"
sdk       = "AROS One 1.3 SDK"
sdk_date  = "2018-04-28"
toolchain = "x86_64-aros-gcc 10.5.0"

Three things, easily blurred

Manifest

Describes the package, and travels inside it.

Index

Points at an archive and records its hash.

Local registry

Describes the actual installation on one machine, including which requirements were satisfied and which were left undetermined.

Where the ideas come from

Neither of these is a claim of compatibility with anything.

Homebrew keeps package definitions as readable files in a Git repository, identifies sources by URL and checksum, and has a test block that checks the installed thing actually works rather than that files landed. What that gives us: definitions in Git as the source of truth with the index derived from them, checksums that are never optional, and the habit of treating "it installs" and "it runs" as two separate claims.

RPM is the package format, and the low-level tool and database that install one. DNF is the layer above: it resolves dependencies, manages repositories and decides what to fetch. What that gives us: the explicit vocabulary of requires, provides and conflicts, and the split itself, which is why every decision lives in one library and pkg is only a front end to it. One honest difference: in RPM's vocabulary, what we call a system requirement is a requirement nothing provides, because on AROS the distribution is the provider and no package expresses it. That is why the two had to be separate fields rather than one list with a flag.

Not copied: install scripts and triggers, for the recovery reason above; weak dependencies; epochs; and several versions of one package installed at once.

Independent repositories

A shared manifest would also make independent repositories possible. If the description travels with the package, an author, a community or a distribution could publish a metadata repository of its own — plain static files, no application server — and a client could read more than one, choosing the entries that match its ABI and architecture. This project's public index is already separate from where the binaries live, so this extends a split that exists rather than replacing anything.

None of it is built, and the limits matter more than the idea. A SHA-256 in an index proves a download matches that index. It doesn't authenticate whoever wrote the index, and no signature makes a program good or safe. Identifier collisions between repositories, which source wins, and stopping a stale index from being served in place of a current one are problems to design, not details to fill in.

The three layers stay separate: whoever hosts the binaries, the metadata repository pointing at them, and the client reading one or more of those. Binaries keep coming from AROS Archives. This project doesn't mirror or host them, and that isn't changing.

Nothing in this section exists in the client today, and none of it has been adopted by anyone. The proposal is kept with the project's other design notes.

Every command in pkg 0.2, in the order its help screen lists them. All of them run from the AROS Shell, against the default root SYS:Packages.

pkg update

Fetches the index from arospkg-index over HTTPS and saves it as SYS:Packages/db/index.json. If the download fails, or what arrives isn't a valid index, the copy already on disk is kept.

pkg search [term]

Looks for the term in each package's id, summary and category, ignoring case, and prints each match with its version and architecture. The category is searched but not printed, so pkg search game finds SDLPoP. With no term it lists the whole index. With no match it prints nothing matches. Packages built for the other ABI are left out, with a count of how many, and --all-abi lists them marked [other ABI] as a diagnostic.

pkg list

Prints the name of each installed package (one registry file each, in SYS:Packages/db/installed/), or nothing installed.

pkg info id

Prints the registry entry for one installed package as JSON: name, version, where it came from, the archive's hash, and one line for every file it installed, like this one from zaphod's: { "path":"AUTHORS", "sha256":"02672617a8ac7f1f464ff2eef9b57eca9a0c5e64bcaf756385a8581191f49e55", "size":1645 } sdlpop's record, covering 1074 files, is 139,646 bytes.

pkg install id

Downloads the archive, or uses the copy already in the cache, and checks it against the index. Then it checks every path inside it, moves the package into SYS:Packages/id in one step, and records each file with its hash. An id that isn't in the index is refused, because the index lists only reviewed packages. An installed package has to be removed before it can be installed again. A package built for the other ABI is refused before anything is downloaded, and an unknown or missing ABI is refused rather than guessed at. So is a package whose system requirements this machine doesn't meet. A requirement pkg can't decide either way is installed with a warning, and the doubt is recorded alongside the package.

pkg remove id

Hashes the package's files on disk, deletes the unchanged ones and removes directories left empty. Files you edited, and files it doesn't recognise, are kept with a warning and listed in a report. The report is written before the registry entry is deleted, so anything left behind can still be traced to its package.

pkg unlock

Clears a lock left behind by a run that died.

pkg doctor [--retry]

Says what is unresolved and why: interrupted transactions, and reports left by earlier removals. It never repairs anything itself. --retry re-runs the ordinary recovery. There is deliberately no force option.

The only options for users are --help, which prints the list of commands, and --version, which prints the build, compiler, toolchain and SDK. The help screen also lists assert-hash, which is a test utility. The remaining options are for the test harness or for diagnosis: --all-abi lists packages for the other ABI, and --abi installs one anyway, which the help itself describes as not for use, since it won't start.

arospkg is a command-line tool with no public release yet, and the first of two intended front ends onto the same library. What works has been run. What comes next is being built, and what comes after that is still a plan.

It is developed on mainline and built for ABIv1 and ABIv11. On AROS One, using the ABIv11 build, the full run is confirmed: fetching the index, search, download and installation of ZapHod, and launching its interface. That doesn't confirm the rest of the catalogue, or the same packages on mainline.