Find and install software on AROS.

Match your system’s CPU and ABI. PkgManager is included in the x86_64 ABIv11 archive; the other builds are command-line only.

• x86_64 ABIv110.4.0 · apkg + PkgManager
• i386 ABIv00.4.0 · apkg
• Raspberry Pi, aarch64 ABIv10.4.0 · apkg; network untested
• Mainline, x86_64 ABIv10.3.1 · Experimental
• Macaros, hosted aarch640.3.1 · Experimental

The Pi and hosted Macaros builds are separate. Do not substitute one for the other.

x86_64 ABIv11 has the most test coverage. i386 was checked through download, install, open and removal. The Pi build was checked with a local catalogue under QEMU; its network operations have not been tested.

Release notes and checksums for 0.4.0 · Experimental 0.3.1 builds

Unpack the archive for your system. Close PkgManager and let any apkg operation finish. In the Shell, enter the unpacked drawer, then run:

Copy apkg C:
apkg --version
apkg update

Keep your existing SYS:Packages when upgrading. Moving from 0.3.x to 0.4 requires this manual copy.

Find a program and check its details:

apkg search game
apkg show soliton
apkg install soliton
apkg open soliton

open opens the installed drawer in Wanderer. Start the program from its icon. Packages go into SYS:Packages by default; use --root "Work:Packages" before the command to use another location.

For the desktop interface, run Run PkgManager from the unpacked x86_64 ABIv11 drawer. Click Update index, choose a package and click Install. Open folder takes you to it.

Usage guide · Automate PkgManager with ARexx

• Open the installed program’s drawer from apkg or PkgManager.
• Read package notes after installation and in the details, such as where to put game data.
• See each operation’s result: installation location, a download error, or the files kept after removal.
• Use larger catalogues. The fixed 8,192-value parser limit is gone; a 5,000-package catalogue was tested on x86_64 ABIv11.
• Update apkg itself. Run apkg self-update --check, then apkg self-update. The previous copy stays as apkg.old. Update PkgManager separately from the release archive.

apkg uses the terminal’s reported capabilities for colours and layout. Commands still work in the ordinary Shell. --plain removes decorations; redirected output and JSON stay plain.

These screenshots are from the 0.4 development acceptance run, using test packages. Click to view at full size.

apkg remove keeps files you changed and files apkg did not install, and lists them. An upgrade refuses if it would overwrite a local change.

apkg verify <id> checks installed files. apkg doctor reports unresolved operations; apkg doctor --retry retries recovery after an interruption.

• upgrade changes the packaging revision of the same upstream version. For a different upstream version, remove and reinstall, keeping any files you need. If removal leaves a drawer, move it aside before reinstalling.
• Rollback covers one previous revision and needs its cached archive. Close the application before upgrading, rolling back or removing it.
• System requirements are checked, but dependencies are not installed automatically. Installer scripts and files in shared system directories such as LIBS: are not managed.
• Downloads use HTTPS and SHA-256 checks. The catalogue is not signed; a matching hash does not establish an application’s safety.

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

It runs on macOS, Linux and Windows with Python 3.11 or newer. Support for AROS is experimental. Your source repository can stay private, and packing needs no GitHub account or network.

Upload the ZIP to AROS Archives or your own release page, then submit its URL. The public catalogue records its URL and checksum after a maintainer review. Checks confirm the package, not that the application runs on AROS.

Download apkg-pack.pyz · Authoring guide · Supported metadata

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

The two RFCs below propose a future package format and application-folder format. They are not the format to use for today’s submissions.

RFC · Draft 0 · Not implemented as a standard

Describe what to install, rather than supply a script of installation steps.

This specification describes an archive’s contents and installation requirements. The companion application-folder specification describes how to recognise and launch the installed application. Both are proposals; examples below are invented.

1. Archive layout

exampleapp.zip                 # ZIP or LHA; no new container
    .arospkg/manifest.toml
    ExampleApp/
        ExampleApp
        ExampleApp.info
        Resources/
    ExampleApp.info             # drawer icon

The manifest is UTF-8 TOML at .arospkg/manifest.toml, relative to the archive root. Existing unpackers do not need to understand it.

2. Minimal manifest

schema = 0
id = "exampleapp"
name = "ExampleApp"
version = "2.9"
revision = 3

[[targets]]
os = "aros"
arch = "x86_64"
abi = "v11"

[install]
subdir = "ExampleApp"
icon = "ExampleApp.info"

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

schema

Required integer. 0 identifies this draft; unsupported schemas must not be installed by guessing.

id / name

Required non-empty strings. id is stable and independent of the version; name is the display label.

version

Required string: the upstream version, or the author’s version for an original project. Opaque; this draft defines equality, not ordering.

revision

Optional positive integer: the port or package release for that version, including code and packaging changes. Compare only within the same version; do not display a suffix when absent. How omission participates in ordering remains open.

targets

At least one target, each with non-empty os, arch and abi strings. CPU alone is not compatibility. Unknown compatibility must not be treated as a match.

install.subdir

Required string. Archive-relative directory to install under the user-selected root; an empty string selects the archive root, excluding package metadata. (arospkg 0.3 does not yet exclude it.)

install.icon

Optional archive-relative file. Installed beside the application drawer as its .info, not inside it.

requires_system

Optional list of system requirements. This example names a library and its minimum version. Omission means no requirements declared, not proof that none exist. Probe results distinguish satisfied, missing and undetermined.

3. Installation rules

• Validate the target, requirements, archive paths and destinations before changing the installation.
• Reject absolute archive paths and traversal: no leading slash, colon, backslash or .. path component. Paths use / separators. (arospkg 0.3 already refuses a leading slash, a colon and ..; it does not yet refuse every backslash.)
• Build a complete plan before writing managed files. Record ownership and preserve local changes; a directory is not permission to delete everything beneath it.
• This declarative profile contains no executable installation hooks. Shared destinations such as LIBS: require explicit rules and conflict handling, not inference from directory names.

4. Optional metadata and open extensions

summary, category and license describe the package. An optional, recommended [source] can identify a repository and pinned revision, or a separate source archive and SHA-256. Installation does not fetch sources or enforce licence compliance.

Package-to-package dependencies, shared-file destinations and file roles (program, config, userdata) need further specification. In particular, creating an empty data directory is different from installing seed data or owning future user files. Those rules are not settled by this example.

The repository index supplies download locations, sizes and archive hashes; the embedded manifest does not contain the hash of the archive enclosing it. Installed-file records belong to the manager, not the author’s manifest.

5. Relationship to Installer

Installer executes an application’s installation procedure. Here, the author describes the desired result and the manager plans the procedure. For supported operations, a separate script becomes unnecessary. Legacy scripts may remain a separate compatibility route, without automatically inheriting the declarative engine’s recovery guarantees.

References: AmigaOS installation tooling, Homebrew definitions, and RPM metadata. Open decisions include version ordering, dependency constraints, target identifiers and extension handling. The current authoring tools use a different manifest format. Follow the authoring guide above for supported fields; this RFC remains a proposal.

RFC · Draft 0 · Proposed, not implemented

Make applications easier to install and launch, without requiring users to understand Amiga-specific setup conventions.

Installing Amiga software can mean unpacking a folder, copying files into system directories, or running an Installer script. For someone new to AROS, it is not always clear which steps an application needs. Making those steps predictable removes one obstacle to using AROS as a daily driver.

Other systems separate these jobs. macOS bundles and RISC OS application directories let a file manager present a directory as a launchable application while keeping its contents accessible. Linux package systems use package metadata for dependencies, while desktop entries describe launching.

For AROS: a manifest identifies the application, its requirements and its entry point. A compatible file manager could launch a self-contained application directly from its folder’s icon and offer “Show contents” separately. The companion package specification covers installation, including applications that need shared system files. Metadata does not fix incompatible binaries or supply missing dependencies by itself.

The application remains an ordinary folder, called a “drawer” on Amiga systems. Existing file managers can still browse it and users can launch the executable inside, without arospkg.

Why this fits Amiga conventions

Amiga .info files already carry more than pictures: depending on the icon type, they include ToolTypes, stack size or a document’s Default Tool. The manifest adds the missing folder-level description: which executable represents the application, its version, compatibility and requirements.

The drawer’s icon remains its visual representation; the program’s own icon retains its launch settings. A compatible file manager should reuse those settings, not copy them into a second configuration file. An older file manager still opens the drawer normally. Missing icons and conflicts between icon settings and the manifest require explicit rules, listed below.

1. Folder layout

ExampleApp/
    application.toml           # proposed fixed discovery name
    ExampleApp                 # executable
    ExampleApp.info            # normal program icon
    Resources/                 # existing resource layout
ExampleApp.info                # normal drawer icon

The reader looks for application.toml directly inside the folder. The folder name is unrestricted; executable and resource locations are chosen by the author. Existing file managers can open the drawer and users can launch the program normally. Folder-format compatibility does not make a binary compatible with another OS, CPU or ABI.

2. Manifest

# Proposed syntax; application.toml is not yet a settled filename.
schema = 0
id = "exampleapp"
name = "ExampleApp"
version = "2.9"
revision = 3

[[targets]]
os = "aros"
arch = "x86_64"
abi = "v11"

[launch]
executable = "ExampleApp"
mode = "workbench"
working_directory = "."

Identity, version, revision, targets and optional requires_system reuse the package specification’s types and meanings. They do not establish that a package manager installed this folder.

executable

Required non-empty string. Path to a regular executable file, relative to the application folder.

mode

Required string: workbench or shell. A reader must support the selected launch convention or report that it cannot launch it; it must not silently substitute the other mode.

working_directory

Optional string; defaults to ".", the application folder. Sets the initial working directory, not PROGDIR:.

Draft 0 proposes one entry point shared by the listed targets. For Workbench launches, the design is to reuse the executable’s existing .info settings; this draft adds no TOML copies of ToolTypes or stack size. Missing-icon behaviour and precedence where settings interact with manifest fields still need an explicit contract. Arguments, multiple entry points and file associations are not defined.

3. Reader behaviour

1. Read and validate metadata without executing code. Discovery must not block the file manager’s UI.
2. For a supported manifest, offer Launch and Show contents. A file manager may make Launch the double-click action; Show contents always opens the ordinary directory.
3. Before Launch, recheck the selected executable, target and declared requirements. Refuse a known mismatch or missing requirement. Report an undetermined result rather than presenting it as satisfied.
4. Launch through the declared convention. Do not evaluate manifest strings as shell commands, install dependencies or alter system configuration.
5. When metadata is absent, invalid or unsupported, keep ordinary directory browsing available. An attempted enhanced launch should explain the failure.

4. Validation and fallback

• Use UTF-8 TOML. Reject duplicate keys, wrong field types, missing required fields and unsupported schema versions.
• Resolve launch paths relative to the folder. Reject absolute paths, colons, backslashes and .. components; resolved links must not escape the folder. The executable must exist and the working directory must be a directory.
• Reading a manifest, displaying an icon or browsing a folder never runs code. Metadata is an author’s declaration, not a trust certificate or a sandbox.
• Keep normal .info icons and direct execution available. No arospkg database lookup or background service is required to launch an otherwise working application.

5. Package-manager boundary

The manifest travels with the application; application settings are not moved into a central database. A manager separately records installed files and transactions for upgrades, removal and recovery. Losing those records may prevent safe management, but must not by itself prevent the application from running.

The folder format does not change library lookup, provide private-library isolation or fix hard-coded resource paths. Moving a folder also does not update a manager’s installation records. Relocation and writes outside the folder need separate installation rules.

6. Decisions still open

• Manifest location: adopt application.toml, retain the package manifest, or derive an installed view? Define one authority, not two independently maintained descriptions. It must survive archive subdir selection.
• Launch details: Workbench startup using existing icon settings, missing-icon defaults, Shell I/O, icon-setting precedence and treatment of requirements that cannot be determined.
• Reader limits: manifest size limits, target vocabulary, unknown fields, cache invalidation and path revalidation at launch.
• File operations: whether a bundle-aware move or rename pairs the drawer with its sibling .info; adoption and relocation of managed installations.

7. Possible extensions: what the application can do

These are candidates for later revisions, not fields supported by Draft 0. The next useful step is to describe capabilities, not just an executable.

Document types

Declare supported formats and roles such as viewer or editor. “Open with…” can offer suitable applications; the user keeps control of defaults. This complements a document icon’s Default Tool rather than overwriting it.

Actions

Offer named actions such as “New document”, “Preferences” or “Open terminal here”. Specify accepted inputs and their launch mechanism; do not evaluate a command string assembled from filenames.

Presentation

Reuse descriptions, categories, icons and optional screenshots in the storefront and file manager. Missing artwork must not prevent launch; browsing must not execute code or require a network request.

Optional features

Distinguish a requirement for starting the application from one needed only by a particular feature. Explain what will be unavailable instead of treating every missing component as fatal.

Target variants

Map each supported CPU/ABI target to its own executable when several builds share a folder. Refuse an unknown or ambiguous match. This would extend Draft 0’s single-entry-point model.

Settings and data

Identify configuration, caches and user documents so tools can offer separate backup or reset operations. A path declaration is not permission to delete its contents or claim ownership of a shared directory.

Example: AROS Term. A future action could accept one user-selected directory and offer “Open terminal here” in that directory’s context menu. The file manager would pass the directory through a defined argument or Workbench-message contract, not interpolate it into Shell text. The executable would remain inside the application folder; accepting an external directory as input would be a separate, explicit extension to the launch contract.

A first experiment should check directories with spaces and command-like characters, missing directories, unsupported targets and normal launching without the extension. This is a proposed use case, not a claim that AROS Term already implements an action protocol.

A manually unpacked application could expose these capabilities without registering with arospkg. A later “Manage this installation” action would need separate verification of supplied files and local changes; the manifest alone cannot establish ownership.

7.1. “Open with…” for an image editor

The following snippets use invented extension syntax and invented applications. They illustrate the contract to design, not fields a current reader understands. They would extend a manifest that already has identity and target fields.

# ExamplePaint: proposed extension, NOT Draft 0 syntax.
[[documents]]
mime_types = ["image/png"]
extensions = ["png"]
role = "editor"
action = "open-image"

[[actions]]
id = "open-image"
label = "Edit image"
executable = "ExamplePaint"
mode = "workbench"
input = "files"
multiple = true
delivery = "workbench-arguments"

The executable path is relative to the application folder; selected documents may be elsewhere. This assumes an editor that actually accepts Workbench file arguments. Type detection, conflicting associations and argument delivery need defined behaviour before adoption; a filename extension alone does not prove a file’s content.

7.2. “Open terminal here”

# ExampleTerm: proposed extension, NOT Draft 0 syntax.
[[actions]]
id = "terminal-here"
label = "Open terminal here"
executable = "ExampleTerm"
mode = "shell"
input = "directory"
multiple = false
working_directory_from = "input"

working_directory_from = "input" explicitly permits a user-selected directory outside the application folder; it does not relax the executable-path restriction. Names with spaces or Shell characters remain path data. The terminal must honour its inherited directory. This is the intended experiment for AROS Term, not a claim about its current behaviour.

7.3. The same description in a store and on disk

# ExamplePaint: proposed extension, NOT Draft 0 syntax.
[presentation]
summary = "Create and edit pixel art"
category = "graphics/editor"
icon = "ExamplePaint.info"
screenshots = ["Preview/editor.png"]
homepage = "https://example.invalid/examplepaint"

Asset paths are application-relative. A catalogue would need to publish a derived description and separately available preview assets to show them before download; a path inside an archive is not enough. Local browsing uses available metadata and assets, with fallbacks when images are missing. The schema must settle one location for these fields rather than duplicate the package manifest’s description and category.

References: macOS document-type and bundle metadata, macOS bundles and RISC OS application directories. These extensions propose desktop cooperation, not a central registry required to run applications.

Source, documentation and issues · Releases

Updated 4 October 2026. An independent project by Tomasz Staniak, not affiliated with AROS or AROS Archives.