arospkg 0.6.0

arospkg 0.6.0 adds package relations, larger packages and ordered test releases.

What's new

• Relations. Packages can depend on other packages (with a minimum version), recommend them, conflict with them and replace them. apkg install shows the plan first: dependencies are installed before the package, a replaced package is removed afterwards, and a package that another installed package needs is not removed. PkgManager shows the same plan.
• Larger packages. One file in a package may now be up to 128 MiB unpacked (64 MiB before). Files are unpacked through small fixed buffers, so a large package needs no more memory to install, and every file must match its recorded size and CRC-32 or the package is refused.
• Test releases in order. apkg upgrade and apkg outdated order versions with one -testN, -previewN or -rcN tag and a -rN rebuild tag: 0.9.0-test2-r2, 0.9.0-test4 and 0.9.0 come in that order, and test10 after test9. Versions in other forms are still refused rather than guessed.
• What is new in the catalogue. apkg update lists new packages and updates; apkg recent lists what was added recently. apkg show and PkgManager say whether a build was reviewed automatically and where it was tested.

Compatibility

0.6.0 reads index-v3.json. Catalogue entries that need relations, or that contain a file over 64 MiB, are listed only there: apkg 0.4 and 0.5 do not see them, and would refuse or mishandle them. Everything else stays available to older clients.

Downloads

Build	Included	Status
x86_64 ABIv11 / AROS One	apkg + PkgManager	Stable
i386 ABIv0	apkg	Experimental
x86_64 ABIv1 / mainline	apkg + PkgManager	Experimental

There is no 0.6.0 build for the Raspberry Pi; use 0.5.0 there.

Upgrade

From 0.4.x or 0.5.x:

apkg self-update

This updates apkg only. Download the archive to update PkgManager.

From 0.3.x: unpack the appropriate archive and copy apkg to C:. Keep your existing SYS:Packages.

User guide

Checksums are in the attached SHA256SUMS.

arospkg 0.5.0

arospkg 0.5.0 adds application launching from the Shell and PkgManager.

What's new

• apkg run <id> [files...] and PkgManager's Run button launch installed applications. Workbench applications use their icon's stack and tooltypes; Shell tools return their exit code.
• PkgManager adds Verify, an Installed filter, and a list of files kept after removal. Installed packages remain accessible without a catalogue.
• Package authors can add a [launch] section to their manifest. apkg-pack validates it and generates the application description.
• Application pictures and a Demo store preview future GUI features. Purchases are not available.
• Ctrl-C during connection or TLS setup is now reported as cancellation.

Downloads

Build	Included	Status
x86_64 ABIv11 / AROS One	apkg + PkgManager	Stable
i386 ABIv0	apkg	Tested in QEMU
x86_64 ABIv1 / mainline	apkg + PkgManager	Experimental
Raspberry Pi aarch64	apkg + PkgManager	Experimental; not runtime-tested

Upgrade

From 0.4.x:

apkg self-update

This updates apkg only. Download the archive to update PkgManager.

From 0.3.x: unpack the appropriate archive and copy apkg to C:. Keep your existing SYS:Packages.

User guide · Screenshots

Checksums are in the attached SHA256SUMS.

arospkg 0.4.2

Package management for AROS, with the apkg command-line tool and PkgManager desktop application.

Downloads

Target	Version	Included	Status
x86_64 ABIv11	0.4.2	apkg and PkgManager	stable
i386 ABIv0	0.4.2	apkg	tested under QEMU, see below
x86_64 ABIv1, mainline	0.4.2	apkg	experimental
Raspberry Pi, aarch64 ABIv1	0.4.2	apkg and PkgManager	experimental; compile/link only
Hosted aarch64, Macaros	0.3.1	apkg	experimental

The Raspberry Pi archive is an experimental build for user testing. Both apkg and PkgManager compile and link with Clang 20.1.0 and the native Pi SDK; neither 0.4.2 binary has been run on Pi, emulated or physical. The Folio checksum failure is not diagnosed. --keep-rejected is available to collect evidence. Adding this archive also makes it available through apkg self-update on Pi; that updates only apkg, and PkgManager must be taken from the archive. Users who prefer the previously tested CLI can retain 0.4.0.

0.4.2 screenshots on AROS One.

What's new in 0.4.2

• apkg outdated lists installed packages for which the catalogue has a newer version, with the installed and the new version. An update that exists but cannot be installed on this machine is shown as blocked, with the reason: built for another CPU or ABI, a library the system does not have, or no checksum in the catalogue. Nothing is downloaded to make the list. --all lists every installed package with its state; --json prints one JSON object for scripts. Exit status 0 when the check ran, 10 when there is no readable catalogue.
• apkg update ends with the number of updates and the command that lists them.
• apkg upgrade --all first shows the plan, then upgrades the packages one at a time, each exactly as apkg upgrade <id> would, and reports each. A package that fails, for example because a file you changed would be overwritten, is left as it was and the others continue; the group is not undone as a whole. apkg --dry-run upgrade --all previews every package.
• Ctrl-C stops a download, including apkg update, and leaves nothing behind. Once files are being changed the operation finishes and apkg says the Ctrl-C came too late; upgrade --all then stops before the next package.
• PkgManager: an Updates (N) filter, the update state in the list, the installed version in the Version column (1.0 -> 1.1 where an update exists), the date of the catalogue above the list, Cancel during Update index, and About > Check for a newer version. The ARexx port has a new OUTDATED command.
• Mainline AROS: output redirected to a file is complete. apkg search >file used to come out empty there because of a stdio fault in mainline builds before 2026-09-24.
• --keep-rejected keeps a download that failed its size or checksum test, for a bug report. Verification itself is unchanged.

apkg self-update replaces only apkg. Take PkgManager from the archive.

Install or upgrade

On 0.4.0 or 0.4.1:

apkg self-update

From 0.3.x, or by hand: download and unpack the archive, close PkgManager, copy apkg to C:, then run apkg --version and apkg update. Keep your existing SYS:Packages. On x86_64 ABIv11, start PkgManager from the unpacked folder.

Test coverage

All under QEMU; nothing in this release was run on real hardware.

x86_64 ABIv11, AROS One 1.3 (pool slots v11-1 and v11-2), with the archive's binaries:

• the updates suite: nine packages installed from one catalogue, then a second catalogue gives each a different state (available, available with a conflicting user edit, current, newer installed, blocked by a missing library, versions that cannot be ordered, not in the catalogue, ambiguous, built for another ABI only); outdated as text, --all, --plain, --json and redirected to files; upgrade --all with the conflict refused and the user's files kept (checked by hash); rollback and removal; no catalogue, an unreadable catalogue, and a root with a space;
• Ctrl-C: during apkg update (catalogue kept), during a package download (cache empty afterwards, exit 10), and during the extraction of the first package of upgrade --all (that package finished, the second not started, exit 10);
• the public catalogue: apkg update and an install over the network;
• PkgManager: the Updates filter and Version column, Upgrade from the list through the preview and confirmation, Cancel during Update index.

i386 ABIv0 (pool slot v0-2), with the archive's apkg: the same updates suite (all checks passed), apkg update from the public catalogue, Ctrl-C during a download, and an install over the network.

x86_64 ABIv1, mainline nightly 2026-09-23 (pool slot v1-1), with the archive's apkg: the same updates suite, including every redirected output, apkg update from the public catalogue and Ctrl-C during it. The public catalogue has no packages for mainline, so no install over the network was made there.

Not runtime-tested in this release: PkgManager on anything but AROS One 1.3; both binaries in the experimental Pi archive. The ScreenBar integration remains an internal demonstration and is not included in release archives.

Use the SHA256SUMS from this release to verify your download.

arospkg 0.4.1

Package management for AROS, with the apkg command-line tool and PkgManager desktop application.

Downloads

Target	Version	Included
x86_64 ABIv11	0.4.1	apkg and PkgManager
i386 ABIv0	0.4.1	apkg
Raspberry Pi, aarch64 ABIv1	0.4.0	apkg
x86_64 ABIv1, mainline	0.3.1, experimental	apkg
Hosted aarch64, Macaros	0.3.1, experimental	apkg

The i386 archive was added to this release on 2026-10-08, built from the same commit (v0.4.1). There is no 0.4.1 build for Raspberry Pi: one was built, but it could not be tested, so it was withdrawn. On a Pi, keep 0.4.0; apkg self-update there reports that this release has no archive for that machine and changes nothing.

What's new in 0.4.1

• apkg upgrade moves to a newer version of a program, not only to a newer packaging revision of the same version. Example: apkg upgrade limpet takes Limpet from 0.1.0 to 0.2.0.
• The upgrade works as before: it shows a plan, keeps files you changed, refuses a conflict before changing anything, can be rolled back with apkg rollback, and is recovered if it is interrupted.
• Versions made of numbers and dots are compared as numbers, so 1.10 is newer than 1.9. apkg refuses an older version, the same number written differently (1.0 and 1.0.0), and versions it cannot order (such as 1.3- or v2), and says why. For those, remove the package and install it again.
• PkgManager uses the same rule for its Upgrade button.

Install or upgrade

On 0.4.0:

apkg self-update

From 0.3.x, or by hand: download and unpack the archive, close PkgManager, copy apkg to C:, then run apkg --version and apkg update. Keep your existing SYS:Packages. On x86_64 ABIv11, start PkgManager from the unpacked folder.

Test coverage

x86_64 ABIv11 on AROS One 1.3 under QEMU:

• the upgrade suite: revision upgrades, conflicts, rollbacks, interruptions at three points with recovery, and the new version cases (1.0 to 2.0 interrupted twice and recovered, then upgraded with the user's changes kept; an older, an equal and an unordered version refused; rollback from 2.0 to 1.0);
• Limpet from the public catalogue: 0.1.0 installed, a theme edited, apkg upgrade limpet to 0.2.0 with the edit kept, verify, rollback to 0.1.0 and upgrade again; the upgraded Limpet started.

i386 ABIv0 under QEMU, with the archive's own apkg:

• the same upgrade suite, with the test indexes set to i386: all checks passed;
• apkg self-update from 0.4.0 to 0.4.1.

Use the SHA256SUMS from this release to verify your download.

arospkg 0.4.0-pigui1 — experimental Raspberry Pi GUI

Experimental PkgManager build for native AROS Raspberry Pi aarch64 ABIv1. Built from commit e510769 with Clang 20.1.0 and the native Raspberry Pi SDK. This release contains apkg, PkgManager and its icon.

The included apkg is byte-for-byte identical to the published 0.4.0 Pi binary. It does not fix the reported Folio checksum failure on real Raspberry Pi hardware. Standard apkg self-update continues to use stable releases and does not update PkgManager.

QEMU raspi3b testing confirmed GUI startup, architecture filtering, keyboard search, package details, worker progress, local-cache Folio installation and verification, removal, shutdown, and operation without ARexx. GUI operations were exercised through its ARexx port using a native helper where mouse input was unavailable. No tests were run on physical Raspberry Pi hardware.

Known limitations:

• Mouse input did not reach PkgManager buttons in QEMU; button interactions and About remain untested.
• The icon appearance and launching from Wanderer remain untested.
• Opening the Folio folder produced an unexplained request to insert volume BUILD-REPORT.md. That file remained after removal; the connection between these observations is unconfirmed.
• Catalogue updates and downloads over the network were not tested on Pi.
• The real-hardware Folio checksum failure remains unreproduced.

Archive: arospkg-0.4.0-pigui1.aarch64-aros-raspi.zip (741171 bytes)
SHA-256: 5db204c99b8173bda870d8ce8bdb3f947ae55c7934f5888dad14da4997527a56

apkg-pack 0.1.0

Build packages for arospkg

apkg-pack checks your application folder, creates a ZIP with its manifest, and submits published packages to the arospkg catalogue.

Runs on macOS, Linux and Windows. Experimental support for AROS. Your source repository can stay private.

Download apkg-pack.pyz, install Python 3.11 or newer, and follow the authoring guide.

python3 apkg-pack.pyz init build/MyApp
python3 apkg-pack.pyz check build/MyApp
python3 apkg-pack.pyz build build/MyApp --output myapp-1.0.x86_64-aros-v11.zip
python3 apkg-pack.pyz submit <download-url> --pr

Packing needs no GitHub account or network. build packs, it does not compile, and check does not test the program on AROS.

Known limits: submit --pr is not tested on Windows yet. On AROS, the aros-cpython interpreter needs a running TCP/IP stack to start, and paths are written POSIX style (/RAM/demo.zip).

Optional: an assistant skill for the same steps, npx skills add tomaszstaniak/arospkg --skill aros-package-author.

This release contains only the author tool. The apkg client and PkgManager are unchanged; their current release is v0.4.0.

arospkg 0.4.0

Package management for AROS, with the apkg command-line tool and PkgManager desktop application.

Downloads

Target	Version	Included
x86_64 ABIv11	0.4.0	apkg and PkgManager
i386 ABIv0	0.4.0	apkg
Raspberry Pi, aarch64 ABIv1	0.4.0	apkg
x86_64 ABIv1, mainline	0.3.1, experimental	apkg
Hosted aarch64, Macaros	0.3.1, experimental	apkg

The Pi and Macaros builds are separate. Do not use one as a replacement for the other.

What's new in 0.4.0

• Open an installed program's folder with apkg open <id> or Open folder in PkgManager.
• Read package setup notes after installation and in package details.
• See installation stages and which files were kept during removal.
• Browse larger catalogues. Tested with 5,000 entries on x86_64 ABIv11.
• Update apkg with apkg self-update. The previous executable is kept as apkg.old. PkgManager is updated separately.

Install or upgrade

1. Download and unpack the archive for your target.
2. Close PkgManager, if running, and wait for any apkg operation to finish.
3. Copy apkg to C:, replacing the old executable.
4. Run:

apkg --version
apkg update

Keep your existing SYS:Packages. On x86_64 ABIv11, start PkgManager from the unpacked folder.

Upgrading from 0.3.x to 0.4.0 requires this manual installation. In 0.4.0, use apkg self-update --check to check for future releases.

Test coverage

• x86_64 ABIv11: full regression and release archive tested on AROS One 1.3.
• i386 ABIv0: catalogue download, search, install, open and remove tested under QEMU.
• Raspberry Pi: local install, show, open and remove tested under QEMU. Network access and downloads have not been tested for this build.

See README.txt for details. Use the SHA256SUMS from the matching release to verify your download.

arospkg 0.3.2 — resize-safe CLI progress

Small CLI presentation update for AROS x86_64 ABIv11. PkgManager is unchanged from 0.3.1.

Download progress during resize

Progress now appears as complete lines every 10%, replacing the in-place bar. Each new line uses the current window width, leaves one spare column and omits counters when the window is narrow. This avoids partially erased frames after narrowing. Success, error and cancellation start on separate lines.

Colours and show/search layout remain. --plain, JSON and redirected output are unchanged. Installation, transport and the package database are unchanged.

Install or update

Close PkgManager and finish any apkg operation, unpack the archive, then copy apkg to C:. Keep your existing SYS:Packages database. Start PkgManager from the extracted drawer; it is the same 0.3.1 binary, so existing users do not need to replace it. The archive README includes commands and usage examples.

Checks

• Full host test suite passed, including 17 presentation tests.
• The progress fix ran on AROS One 1.3 under QEMU with Limpet rc5: dark and light themes, narrowing, multiple updates, widening and successful completion; cancellation on both themes.
• Redirected auto/plain show output was byte-identical and JSON parsed correctly.
• The final CLI rebuild changes version identification to 0.3.2; that rebuild was not separately run in the guest. PkgManager is byte-identical to the published 0.3.1 program.

This release contains only the x86_64 ABIv11 archive. Experimental builds for other targets remain at 0.3.1. The existing TLS/entropy assessment limitations are unchanged; this is not a security update.

SHA256SUMS checks the archive. BUILD.txt inside records each program's source revision and hash. Earlier releases are untouched.

arospkg 0.3.1

arospkg 0.3.1: Mbed TLS instead of the SDK's OpenSSL, broken downloads reported as such, and output that uses what the terminal can display.

What is new

• TLS through Mbed TLS 3.6.7 (TLS 1.2 and 1.3), compiled in, instead of the SDK's OpenSSL 1.1.0h; the programs are about a quarter of the size. On AROS One the randomness for TLS comes from jitterentropy-library 3.7.0; if it is unusable on a machine, apkg refuses to connect and never falls back to anything weaker.
• Broken downloads are reported as such ("the connection to HOST broke after N of M bytes: connection reset", or the TLS error) instead of "the download is the wrong size". Nothing partial reaches the cache.
• Terminal-aware output. In a terminal that answers the presentation query (Limpet, AROS XTerm), show, search and install use bold, coloured verdicts, the window's width and a progress line that updates in place. In an ordinary Shell window the text is as before, with a progress line every 10% of a download. New options --plain and --color=auto|always|never. Redirected output and --json are unchanged.

AROS One (x86_64, ABIv11): tested

arospkg-0.3.1.x86_64-aros-v11.zip: apkg ca448171…, PkgManager 9df4f771….

• The full regression on AROS One 1.3 (QEMU) with the new TLS: install, upgrade, rollback, removal, interruption and recovery, refused downloads (bad certificates, plain HTTP, redirects to HTTP, a failed entropy source), the release-archive check, PkgManager's window and its ARexx port.
• Downloads made to break: reported as a broken connection or a TLS error; nothing cached, the lock released; the next attempt succeeds, also in the same PkgManager window.
• The new output with Limpet on a dark and a light theme: verdict colours, width, the live progress line while the window was resized, cancelling, the prompt after each command; redirected output identical.
• This final archive was unpacked on AROS One and run: version and hash, update, show, search, install, verify and remove of a real package, PkgManager's window.

Reports: docs/reports/ (2026-10-02-rc2, 2026-10-02-presentation-joint and earlier).

Other targets: experimental

archive	state
x86_64-aros-v1 (mainline), apkg db658fe6…	built; the same code as the rc2 build that started on mainline, where the network was not tested (the test machine had no working DNS)
i386-aros-v0, apkg bd24acc8…	built; the same code as the rc2 build that ran on ABIv0 with TLS, a test index and a broken download
aarch64-aros, apkg b967b053…	built only; not runtime-tested. Hosted Macaros needs a posixc.library built for it

The catalogue offers x86_64 ABIv11 packages only; on the other targets search hides them and install refuses them.

Limits

• The entropy source was measured on one configuration (AROS One under QEMU): the runtime criterion of jitterentropy's own procedure is met there; the restart part was not completed. This is not a certification.
• The terminal-aware output was checked with Limpet on AROS One only; not on mainline or through a PTY.

Checksums

SHA256SUMS lists the archives; BUILD.txt in each archive names the commit and the programs' SHA-256.

arospkg 0.3.1-rc2 (release candidate)

Release candidate for testing, not a release. arospkg 0.3 remains the current version.

What changed from 0.3.1-rc1

A download whose connection breaks is now reported as such, for example "the connection to release-assets.githubusercontent.com broke after 2523122 of 2593505 bytes: connection reset" (or the TLS error), instead of "the download is the wrong size". The partial download is still discarded and nothing reaches the cache; only the message changed. The TLS layer keeps the socket's own error and tells it apart from a TLS error and from a normal end of the stream.

Everything else is as in 0.3.1-rc1: Mbed TLS 3.6.7 compiled in, entropy from jitterentropy-library 3.7.0 on ABIv11, i386 and hosted aarch64 and from getentropy() on mainline, no fallback.

What was tested (exact rc2 binaries)

archive	status
x86_64-aros-v11, apkg 977f52ad… and PkgManager a97d0390…	full regression passed on AROS One 1.3 (QEMU), including the release-archive check, the package cycle and the window flow; broken-download test passed in the CLI and in PkgManager, including a successful next install in the same window
x86_64-aros-v1 (mainline), apkg 0c2f93d9…	starts (version and hash checked); network not run: the test machine had no working DNS. Experimental for this candidate
i386-aros-v0, apkg 1d28053c…	runs, TLS checked, package cycle with a test index, broken download reported correctly; not a full regression
aarch64-aros, apkg dae89bf3…	built only: experimental, not runtime-tested

The entropy assessment is unchanged from rc1 and still not complete (the runtime criterion is met in the configuration measured; the restart series is incomplete). This candidate is not an approved security update.

Reports: docs/reports/2026-10-02-rc2/ on branch mbedtls.

Testing it

See README.txt in each archive: unpack it anywhere and use --root with a drawer of its own; it does not touch an installed arospkg 0.3.

SHA-256

See SHA256SUMS.