amipkg 0.7.9

Fixes two independent bugs that between them made amipkg install fail on any
machine with a current AmiSSL — while iBrowse and LumiFTP worked fine, which made
it look like amipkg's own fault rather than a version handshake. It was both.

1. AmiSSL version pinning

amipkg asked for AMISSL_V11x, which the SDK header defines as AMISSL_V110d —
the AmiSSL v4.0-era OpenSSL 1.1 API. AmiSSL 5.2x ships only the OpenSSL 3.x
line (amissl_v5 / amissl_v362), so InitAmiSSLMaster() accepted the request
and OpenAmiSSL() then found no 1.1 implementation to hand back. A current,
healthy AmiSSL failed with "couldn't open AmiSSL", and the neighbouring branch
would have reported "too old" when the truth was the opposite.

Pinning any single level is wrong in one direction or the other:
AMISSL_CURRENT_VERSION is baked in at build time and rejects good older
installs; AMISSL_V11x rejects good newer ones. amipkg now walks a list from
newest to oldest and takes the first that both initialises and opens.

Diagnosed against two machines: an A4000 with amisslmaster 5.22 +
amissl_v111m worked, a PiStorm/Emu68 box with 5.27 + amissl_v362/amissl_v5
did not. The deciding factor was which implementation library was installed,
not the AmiSSL version.

2. Signed download URLs were truncated

With TLS working, GitHub release downloads then failed as HTTP 618 — not a real
status, just a garbled parse. GitHub's release-asset redirect carries a signature
in the query string and runs to about 915 characters; path[512],
redirect[512] and req[768] cut it mid-signature, so the request went out
malformed. All are now sized from AMIPKG_URL_MAX (2048).

This one was hidden behind the first — it would have hit every GitHub-hosted
package the moment AmiSSL was fixed.

Verified end to end on both machines: fetch, redirect, SHA-256 verify, install.

amipkg 0.7.8

amipkg 0.7.8 — the Refresh button comes back, and one word for one action

Refresh existed in the menu but not in the window

The GadTools GUI's button column grew an entry in 0.7.6 (Update Selected)
and the loop that creates those buttons was never told there was one more — so
the last button in the list, Refresh, simply stopped being drawn. Two
releases with a button that the code still handled, still enabled and disabled
correctly, and never showed.

It is back, and the loop now counts the buttons itself so adding one cannot do
this again.

One word for one action

The same action was called three different things depending on where you looked:
the GadTools GUI said Update, the MUI GUI said Upgrade Selected, and
both then asked "Upgrade every out-of-date package?" after you pressed
Update All. The CLI printed "Upgrade amipkg 0.7.7 -> 0.7.8" in the log
window underneath.

Everything now says update. Both GUIs show Update Selected next to
Update All — with the scope spelled out, because a bare "Update" beside
"Update All" reads like a weaker version of the same command rather than
"just this one".

The command you type is unchanged: amipkg update still refreshes the catalog
and amipkg upgrade still installs newer versions. Only what you read changed,
so existing scripts and habits keep working.

"no output" now says what it means

When a shelled-out command produced nothing at all, the GUIs reported
"(no output — check RAM:amipkg-gui.out)" and sent you to an empty file.

An empty output file does not mean the command failed quietly — it means the
command never started, and on a 68k machine that is nearly always memory:
amipkg has to load and hold the whole catalog (200+ packages) on top of a
resident Workbench, MUI and dock. The requester now says that and tells you
what to do about it, including the setting emulator users need.

Upgrading

amipkg upgrade

amipkg 0.7.7

amipkg 0.7.7 — updating amipkg can no longer leave you without amipkg

A user updating from the GUI on an A4000 watched the program disappear from
its drawer mid-update. Nothing was lost — the new files were on disk, in the
home drawer — but the app he had launched was gone, and that should not be
possible. This release makes it impossible.

An upgrade no longer removes before it installs

Upgrading any package used to remove the old version first and install the new
one after. For any other program that is merely tidy. For amipkg upgrading
itself it means a moment when there is no amipkg on the machine at all and no
second copy anywhere — and anything that goes wrong in the copy phase leaves
you with nothing to run.

amipkg now installs over the previous version and cleans up afterwards,
once the replacement is known to be on disk. If a self-upgrade fails now, the
version you were running is still there, still working.

The cleanup is deliberately narrow: it only removes files inside amipkg's own
home drawer, and only ones the new version genuinely no longer ships. A stale
file left somewhere else is harmless; deleting something outside the home on
the strength of an old record is exactly how a running program gets erased.

PROGDIR: no longer goes into the receipt

The record of amipkg's own files listed them as PROGDIR:amipkg and so on.
PROGDIR: means "the drawer of the program running right now" — fine when it
is written, wrong when it is read back later by a different amipkg, such as
the CLI a GUI starts. Since an upgrade deletes the recorded paths, a record
written in one drawer could delete the app in another.

Paths in the receipt are now absolute, and match the names the installer
writes, so the two always describe the same files.

Receipts already written this way are repaired automatically the next time
amipkg starts. Every machine that has run an earlier version has one, so
fixing only new installs would have left them as they were.

If an update ever looks like it emptied the drawer

It probably did not. Workbench does not redraw an open window when files are
replaced underneath it — close and reopen the drawer, or check from a Shell
with List. And a complete copy of the new version is always kept at
<amipkg drawer>/cache/extract until the next download.

Upgrading

amipkg upgrade

Nothing else changed: same catalog, same repositories, same packages.

amipkg 0.7.6

amipkg 0.7.6 — update one package, multi-platform packages, tidier system installs

Update a single package

Both GUIs had Update All but no way to update just one thing — even though
the CLI has taken amipkg upgrade <id> all along. There is now an Update
button beside Update All (and Package → Update, shortcut G).

It is only active when there is genuinely something to do, and the same check
marks the list: outdated packages show UPDATE in the status column instead
of a flat "installed", so you can see what is worth acting on without running
Check Updates first.

Packages can name several platforms

0.7.5 introduced the Architecture field. Real Aminet readmes list several
platforms, comma-separated — m68k-amigaos,ppc-amigaos,ppc-morphos — and 0.7.5
only understood a single value, so a multi-platform package was hidden
everywhere. It now runs wherever any of its listed architectures does.

If you are on 0.7.5, upgrading matters: the catalog already carries such a
package (imp3handler), and 0.7.5 cannot see it.

Installing into C:, LIBS:, DEVS: … does the right thing

Point a package at a system drawer and, until now, the whole archive tree went
there — documentation and all. Worse, an archive bringing its own top drawer
landed nested, so a command installed to C: ended up at C:Tool/Tool, where
the shell will never find it.

System drawers hold flat, specific things, so:

• programs go in flat — C:Tool, not C:Tool/Tool
• everything else goes beside them, in <install drawer>/<id>, structure
  intact

Both halves are recorded, so remove still cleans up either way, and amipkg
tells you how the split went. Nothing changes for ordinary app drawers —
SYS:Programs behaves exactly as before.

Also fixed

Three internal buffers were still sized for the short AMIPKG: prefix although
the resolved path has been absolute since 0.4.7 — on a machine with a long
install path that could have silently truncated a receipt or config path.

Upgrading

amipkg upgrade

amipkg 0.7.5

amipkg 0.7.5 — an Architecture field, so a catalog can serve more than 68k

Suggested by djbase, who runs the first external repository and had no way
to publish anything that isn't 68k.

requirements.architecture

Aminet's vocabulary, so you write what you already know:

"requirements": { "architecture": "ppc-morphos" }

m68k-amigaos, ppc-morphos, ppc-amigaos (OS4), i386-aros /
x86_64-aros / ppc-aros / arm-aros, ppc-warpup, ppc-powerup, and
generic for documentation or data that runs anywhere.

Absent means m68k-amigaos. The catalog predates the field, so the default
has to be the platform everything was written for — every existing entry stays
valid, and nothing changes on a classic Amiga.

It filters, and it stays honest about it

amipkg now detects what it is running on and hides packages that machine cannot
use — refusing to install one if you ask directly, alongside the existing CPU
and Kickstart checks. Both GUIs do the same and show the architecture in Info.

Two things worth knowing:

• MorphOS and AmigaOS 4 still see the whole 68k catalog. Both run m68k
  binaries, so the filter removes only what is genuinely unusable rather than
  leaving those machines with almost nothing. (amipkg itself is an m68k binary,
  which is exactly why it can already run there.)
• Nothing disappears without a way to look. avail reports how many entries
  it hid, and amipkg avail ALL lists everything with the architecture named.

For repo owners

HOSTING.md covers the field. An architecture outside the list is a validation
error, not a warning — an unrecognised value would silently hide the package
from every machine, which is worse than a typo you can see.

Upgrading

amipkg upgrade

amipkg 0.7.4

amipkg 0.7.4 — update one package, and install into system drawers properly

Update a single package from the GUI

Both GUIs had Update All but no way to update just one thing — even though
the CLI has taken amipkg upgrade <id> all along. There is now an Update
button beside Update All (and Package → Update, shortcut G).

It is only active when there is genuinely something to do, and the same check
marks the list: outdated packages now show UPDATE in the status column
instead of a flat "installed", so you can see what is worth acting on without
running Check Updates first.

(A package you adopted whose version could not be detected never claims a
false update — an unknown version is not treated as outdated.)

Installing into C:, LIBS:, DEVS: … now does the right thing

Point a package at a system drawer and, until now, the whole archive tree went
there — documentation and all. Worse, an archive that brings its own top drawer
landed nested, so a command installed to C: ended up at C:Tool/Tool, where
the shell will never find it.

System drawers hold flat, specific things, so that is what amipkg does now:

• programs go in flat — C:Tool, not C:Tool/Tool
• everything else goes beside them, in <install drawer>/<id>, with its
  structure intact

What belongs there is deliberately careful: name conventions first
(.library, .device, .class, .font, .prefs) and the executable header
for the drawers that hold plain commands. Anything unrecognised goes to the
companion drawer, where it does no harm. Both halves are recorded, so remove
still cleans up either way, and amipkg tells you how the split went.

Nothing changes for ordinary app drawers. Installing into SYS:Programs —
what almost everything does — behaves exactly as before. This only engages when
you deliberately choose a system drawer, which pairs with the per-package
install drawer from 0.7.2:

amipkg install <id> DIR=C:

Also fixed

Three internal buffers were still sized for the short AMIPKG: prefix although
the resolved path has been absolute since 0.4.7 — on a machine with a long
install path that could have silently truncated a receipt or config path.

Upgrading

amipkg upgrade

Thanks again to yelworC and djbase, whose reports drove most of 0.7.x.

amipkg 0.7.3

amipkg 0.7.3 — installing into system drawers

Installing into C: (or LIBS:, DEVS:, S: …) now does the right thing

Point a package at a system drawer and, until now, the whole archive tree went
there — documentation and all. Worse, an archive that brings its own top drawer
landed nested, so a command installed to C: ended up at C:Tool/Tool, where
the shell will never find it.

System drawers hold flat, specific things, so that is what amipkg does now:

• programs go in flat — C:Tool, not C:Tool/Tool
• everything else goes beside them, in <install drawer>/<id>, with its
  structure intact

What counts as belonging there is deliberately careful: name conventions first
(.library, .device, .class, .font, .prefs) and the executable header
for the drawers that hold plain commands. Anything unrecognised goes to the
companion drawer, where it does no harm. Both halves are recorded, so remove
still cleans up either way, and amipkg tells you how the split went.

Nothing changes for ordinary app drawers. Installing into SYS:Programs —
what almost everything does — behaves exactly as before. This only engages when
you deliberately choose a system drawer, which pairs with the per-package
install drawer added in 0.7.2:

amipkg install <id> DIR=C:

Also fixed

Three internal buffers were still sized for the short AMIPKG: prefix, although
the resolved path has been absolute since 0.4.7. On a machine with a long
install path that could have silently truncated a receipt or config path.

Upgrading

amipkg upgrade

Thanks to yelworC and djbase, whose reports drove both 0.7.2 and this.

amipkg 0.7.2

amipkg 0.7.2 — from the first week of external repos

Everything here comes from testers running 0.7.x for real. Thanks to djbase,
who set up the first external repository, and yelworC for the install-drawer
reports.

Choose where each package goes

One global install drawer was not enough — a tool may belong in C: while
everything else belongs in SYS:Programs. You can now decide per package:

amipkg install <id> DIR=<drawer>    install there, and remember it
amipkg dir <id> <drawer>            set one package's drawer
amipkg dir <id> -                   clear it, follow the global again

The choice is stored before the install, so it governs later upgrades too.
Both GUIs get Install To… next to Install.

Adopt now reads the version that is actually installed

amipkg adopt used to record "unknown" unless you passed a version by hand,
and the GUIs then quietly displayed the catalog's version instead — which
looked right until you disabled the repository and it vanished.

Adopt now reads the $VER: string out of the binaries, exactly as C:Version
does, so what you see is what is on your disk. When a version genuinely has to
come from the catalog it is shown as 1.3?, because it is a guess and should
look like one.

Already adopted something? Adopt it once more to pick up the real version.

Hosting your own repository: corrected docs, and a safety net

The catalog example in HOSTING.md was wrong in two ways, and both made the
client reject the catalog outright:

• "schema" must be exactly 1 — it is the format version, not yours
• the download belongs in archive (url / sha256 / sizeBytes), not in
  install

Both are fixed. More importantly, amipkg-repo-sign now validates before it
signs and refuses to produce a signature for a catalog the Amiga could not
read, so a typo fails on a machine with a screen instead of on someone's A4000:

amipkg-repo-sign check packages.json     lint without signing

Upgrading

amipkg upgrade

amipkg 0.7.1

amipkg 0.7.1 — interface polish

A follow-up to 0.7.0 that brings both GUIs in line with the
MorphOS/MUI Style Guide. No functional
changes — everything from 0.7.0 (multiple repositories, the repository manager,
repo:package) works exactly as before.

What changed

A proper Settings menu. Install Drawer… and Repositories… moved out of
Package — they configure amipkg, they aren't things you do to a package. The
MUI build also gains Settings → MUI… for the local interface settings, as
every MUI application should.

The first menu is now named after the app rather than Project, which by
convention belongs to programs that load and save project files.

? opens About, the standard shortcut everywhere on Amiga. It had been
sitting on Documentation.

Input fields are labelled with a colon, so it reads as Name: / URL: /
Public key: and it's clear which field a label belongs to.

All of it applies to the GadTools build as well as the MUI one — these are
Amiga interface conventions, not MUI-only ones, and the two front-ends are kept
deliberately identical.

Not adopted

The guide suggests Aboutbox.class for a uniform About window. amipkg sticks to
MUI 3.8 stock classes so it runs on a plain OS 3.x install with no extra
class installed — that matters more here than a tidier About box.

Upgrading

amipkg upgrade

amipkg 0.7.0

amipkg 0.7.0 — host your own repository

amipkg can now install from more than one repository, and anyone can run one.

A repository is just two static files on any web server — packages.json and
its signature. No database, no PHP, no HTTPS needed. A club, a developer shipping
their own builds, or you, for your own machines.

amipkg repo add mystuff http://your.host/amiga <public-key>
amipkg update

What's new

Multiple repositories. Add as many as you like. The official catalog keeps
working exactly as before — if you never add one, nothing changes for you.

Order is priority. The first repository that has a package is the one you
get, and you decide the order with amipkg repo up / down. Want a specific
repo's build regardless? Ask for it by name:

amipkg install mystuff:ibrowse

A repository manager in both GUIs. Package → Repositories, in the GadTools
and the MUI front-end alike: add, remove, enable, disable, reorder. amipkg info
and both GUIs show which repository a package came from, so nothing is a mystery.

Dependencies resolve across repositories. A package in one repo can satisfy a
dependency declared in another — they behave as one catalog, not silos.

Your own repo can be signed, and it's easy. tools/amipkg-repo-sign makes a
keypair and signs your catalog with no dependencies at all — Python 3 and nothing
else. Your users then get exactly the same guarantee as the official repo: amipkg
verifies the signature on the Amiga before it will use a catalog, so even
over plain HTTP nobody between you and your users can alter what they install.

Unsigned repos are allowed too, if you want one — amipkg explains the
trade-off once and asks. It's a fair choice on your own LAN. It's a poor one for
strangers over the internet, because an unsigned catalog can be rewritten in
transit, and the archive checksums can't save you: they live inside the very
catalog that was rewritten.

New guide: HOSTING.md walks through both paths end to end.

Open by design

amipkg is Apache-2.0 and the whole chain is inspectable: the client, the
catalog, the signing tool, the schema. Now the repository side is open too —
you no longer need anyone's permission to publish Amiga software to your own
users. If you'd rather reach everyone by default, the official catalog is still
one command away (amipkg submit), human-reviewed and signed offline.

Compatibility

Nothing to migrate. Existing images keep their catalog exactly where it is and
keep updating from the official repo as before.