Soar 0.13

0.13.4

Soar 0.13.4 lets a declaration ask for a system-wide install, and settles several places where soar chose the wrong version or wrote the wrong thing back to packages.toml.

System-Wide Packages In A Declaration

A package in packages.toml can be marked system = true:

[packages]
ripgrep = "*"

[packages.docker]
version = "*"
system = true

soar apply installs the unmarked packages into your own tree as before, then hands the marked ones to a second pass over the same file that asks for root and installs them under the system root. A file with nothing marked spawns nothing and asks for no password. Packages declared in /etc/soar/packages.toml are system-wide by definition and need no marker.

--prune carries through to that pass, which keeps whatever /etc/soar/packages.toml declares. One user pruning against their own file cannot remove the packages an administrator put there.

Bug Fixes

• soar apply installs the newest version a declaration allows. It took whichever row the metadata returned first, which was the oldest
• A version = "*" declaration stays "*". Only the sources with no registry to ask, meaning url, github, gitlab and version_command, record the version they installed
• A version recorded that way is written to the packages file that was applied, rather than to the configured default
• System mode reads packages.toml from /etc/soar. It read the invoking user's home, which under sudo is root's
• soar -S defpackages writes the system packages file rather than failing to write the user's
• The package picker lists the newest of each package rather than every version of every one. An older version is installed by naming it, as pkg@1.2.3
• The Icon field soar writes into a desktop entry, and the icon file it links alongside it, are named after the entry's own Name rather than after the file the package shipped as. An AppImage calling itself desktop no longer loses its icon to the theme's generic one of that name. The desktop file keeps its existing name, and a package already installed takes the new icon name when it is next installed

0.13.3

Soar 0.13.3 is a maintenance release. It shows that a command is waiting on the network, and fixes the metadata database, system-mode escalation and zsync.

Waiting Visibly

Commands that resolve packages over the network show a spinner while they wait, rather than printing nothing until the remote answers.

Bug Fixes

• Metadata JSONB columns are converted once rather than on every database open
• The batch progress bar is cleared when its batch finishes
• System mode escalates only for the commands that write. A read answers from the system tree as the invoking user rather than asking for a password
• zsync requires HTTPS and honours a pinned checksum

0.13.2

Soar 0.13.2 makes soar reachable from a browser and from other programs. It adds a handler for soar:// links, JSON output with a manifest describing how to drive soar, and riscv64 builds of soarpkgs.

soar:// Links

soar url soar://install/<package> installs from a link, and soar url --register registers soar as the handler for the scheme so a browser can open one.

Registering writes soar-url-handler.desktop into ~/.local/share/applications, with its Exec line pointing at the soar that registered it, and then points the x-scheme-handler/soar MIME type at that entry. The entry is NoDisplay, so it stays out of the application menu, and Terminal=false, because soar opens a terminal itself rather than leaving the choice to the fixed list of terminals a desktop environment happens to know.

A link is untrusted input that reached the machine without anyone typing it, and is treated as such. It is capped in length, rejected if it carries escapes or a query string, matched against an allowlist of actions rather than sanitized, and confirmed on a terminal before soar installs anything.

Driving Soar From a Frontend

--json makes commands emit one JSON document per line instead of formatted output, and soar plugin-manifest prints how a frontend should drive this particular soar.

riscv64

soarpkgs is served for riscv64.

Bug Fixes

• A desktop entry's Exec line leaves no trailing space when the command takes no arguments
• The plugin manifest lets update name the package it means
• The registry reads the date the metadata actually publishes
• soar search matches a package whose family the metadata has dropped
• soar update lets the artifact decide the version where the version string cannot

0.13.1

Soar 0.13.1 is a maintenance release. It adds control over which address family connections use, makes downloads more resilient, and honours proxy settings from the environment.

Choosing an Address Family

--ipv4 (-4) and --ipv6 (-6) restrict connections to a single address family. By default soar tries every address a host resolves to, in whatever order the system resolver returns them, waiting out a 30 second connect timeout per address before moving on. That wait is what these flags avoid: on a network that advertises IPv6 but silently drops the traffic, -4 skips the IPv6 addresses rather than stalling on each one. The two flags cannot be combined.

Proxies From the Environment

When no --proxy is given, soar now falls back to the ALL_PROXY, HTTPS_PROXY and HTTP_PROXY environment variables, honouring NO_PROXY for hosts that should bypass the proxy. Passing --proxy overrides all of them. Connections also carry a 30 second bound on the TCP connect and TLS handshake, so an unroutable address fails over to the next one rather than hanging.

Bug Fixes

• A download reports the underlying error when it fails, rather than a generic message
• A download no longer fails on a filesystem without extended-attribute support
• A system-mode database is created when its location is writable, rather than being skipped
• soar info prints its entries in the same family/name query format the rest of the CLI uses

0.13.0

Soar 0.13.0 reads the declarative package format, stops requiring a package id, and gives packages installed from a URL a way to update themselves.

Breaking Changes

A package id is no longer required. Repositories publishing the declarative format have none, so pkg_id is optional throughout. What tells two identically-named packages apart is the family, the project a package comes from, and the query syntax follows. Where two projects both publish a command called cat:

soar install busybox/cat     # family/name
soar install cat#busybox     # deprecated, still parses and warns

packages.toml gained family, and deprecated two fields. pkg_id still works and warns; install_patterns is only applied by the OCI download path and is ignored by the declarative format.

[packages]
cat = { family = "busybox" }

soar remove '<name>#all' is gone. It selected every variant and then removed only the one you chose, which is what a bare name already does. Use --all to remove every variant:

soar remove --all cat

The metadata database schema changed. This is the database soar keeps locally for each repository, and what a repository has to do about it depends on what it publishes.

• A JSON index: nothing. Soar builds the database from the index, so it is built to the current schema. Fields soar no longer keeps, pkg_webpage, tags, version_upstream and binaries, are ignored rather than rejected, and an index in the original bare-array form is still read.
• A prebuilt SQLite database: nothing immediately. One built by an older soar is brought up to the current schema when it is fetched, so it keeps working until the repository publishes a new one.

Packages install by path. Where a repository says what a package contains, each file lands where it belongs inside the package directory, and soar links manual pages and shell completions onto the system alongside the commands.

Updating Packages Installed From a URL

A package installed from a URL now records where it came from, and can be updated. You can name it by that URL or by the name it installed under:

soar install https://github.com/owner/repo/releases/download/v1.2.3/tool-linux-x86_64.AppImage
soar update tool
soar remove https://github.com/owner/repo/releases/download/v1.2.3/tool-linux-x86_64.AppImage

Soar decides what to update to in two steps. If the artifact carries a feed, an AppImage recording one in its .upd_info section, that is the publisher's own statement of how the package updates and it is followed first. Otherwise, where the URL points at a GitHub or GitLab release, the newest release of that project decides, which is what covers archives and plain binaries.

Delta Updates Over zsync

A publisher offering a zsync feed publishes a control file describing the artifact block by block. Soar uses it to decide whether the artifact differs from the installed copy without downloading it, and then to fetch only the blocks that changed, reusing the rest from the copy on disk. The result is verified against the control file's checksums before it replaces the package.

Manual Pages and Completions

An install now links manual pages beside the bin directory, where man finds them through PATH with no MANPATH set, and shell completions into the directory each shell reads. The completions setting chooses which shells to link for, defaulting to those whose completion directory already exists. Removing a package unlinks only what points back into it, so anything your distribution installed is left alone.

Bug Fixes

• The version of a package installed from a release URL is taken from the release tag rather than guessed from the filename, so an asset named tool_x86_64-unknown-linux-musl.tar.gz no longer installs as tool_x86 at version 64
• A rolling build that keeps one version across every build is updated when its contents change, rather than being treated as already current
• An update check that cannot reach a release now says why, rather than reporting that nothing needs updating
• An empty GITHUB_TOKEN or GITLAB_TOKEN is ignored rather than sent, which previously earned an authentication failure on every request

TIP

GitHub allows 60 API requests an hour unauthenticated, which a handful of packages checked repeatedly will reach. Set GITHUB_TOKEN or GH_TOKEN to raise it. See Forge Rate Limits.