Find and install software on AROS.

The catalogue holds 27 programs today: games, editors, file tools and Shell utilities. Every one of them was installed, started and removed on AROS before it was listed. Started means it opened its window or printed its output; it isn’t a promise that every feature of every program works.

Also: antiword, bin2iso, blips, ccd2iso, dirtree, gmore, grep, hocoslamfy, iconmake, isomaker, isotool, ominostage, rescode, shooterspace, skandalfoclock, unlzx, untangle, xrick and zunecalc.

apkg update

Fetches the current catalogue. It doesn’t change any installed program.

apkg search [word]

What the catalogue offers, matched against names, summaries and categories.

apkg install id

Downloads, checks and installs a package into SYS:Packages.

apkg list

What is installed.

apkg remove id

Removes a package and keeps any file you changed.

apkg upgrade id

Moves to a newer packaging of the same program version, and shows the plan first.

apkg rollback id

Goes back one step, to the packaging the last upgrade replaced.

apkg verify id

Compares the installed files with the record and says which changed. It repairs nothing.

--dry-run

With install, remove, upgrade or rollback: shows what would happen and changes nothing.

apkg doctor

Explains anything left unfinished after an interruption. --retry finishes or undoes it.

apkg --help lists everything, including options that exist for testing.

arospkg doesn’t host any programs. It publishes a small public catalogue that points at each program where its author published it: AROS Archives for most of them, and a project’s own release page for some, such as GrafX2, Folio, Micropolis and OpenLoco. For each package the catalogue records the size and SHA-256 the download has to match, what it needs from the machine, and where it goes.

The catalogue is at github.com/tomaszstaniak/arospkg-index. A package goes in only after its archive has been downloaded, checked, and installed, started and removed on AROS.

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

apkg search zaphod
zaphod               1.3        x86_64    A simple binary file editor

apkg 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

apkg list
zaphod

apkg remove zaphod
removed zaphod

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. Today arospkg uses reviewed catalogue metadata; it does not consume this embedded standard.

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.

More programs in the catalogue, before more features in the manager. The next ones are AROS ports that already have releases of their own, each installed, started and removed on AROS before it is listed.

After that, and designed but not built: installing files into LIBS: and Fonts:, declared file by file by the package’s author, with what was there kept and a library never downgraded; and a signed catalogue.

Along the way, two fixes went into AROS mainline: a library that was never being built, and a 64-bit sign-extension bug that broke every TLS connection through the generic socket path.

Snapshot: 26 September 2026. arospkg is an independent project by Tomasz Staniak. It is not affiliated with AROS, AROS Archives or any AROS distribution.