APS:Overview

Introduction

A proper packagemenet system for Amiga has been sought after for a long time. There has been several attempts but they either never surfaced, are implemented in a closed and impractical manner or simply just lacks vital functionality like dependecies or install/removal scripts.

This effort seeks to provide an open, easy system that takes advantage of existing repositories like Aminet and its usage. The project should result in a server framework that takes advantage of mirrors and existing metadata, some tools to manage programs at client side and a well-documented format for package files.

Server

A server will provide a list divided into architectures of available packages. this would be similar to the exisiting INDEX file, but with many of the .readme headers contents. This file must be compressed to save bandwidth. A diff version showing only packages after a given date might be an option.

Package files

A package file should have its own extension so that the management tool can treat it as a package file. For instance .aps.

A package file should be a regular -lh7- packed lha containing a relative hierarchy. A special dir called .aps should be used to include pre and post installation scripts and more.

A package's readme file should be used to store info about dependencies and similar.

The .aps metadata directory

A special directory named .aps should reside inside an .aps package file. This directory is used to store scripts which are run upon removal or installation. In addition it can be used to store configuration files or templates that the scripts might wish to install.

APS:Example package hierarchy

Scripts

The .aps dir should contain none or all of the following scripts:

preinst Before copying files
postinst After copying files
prerm Before deleting files
postrm After deleting files
They should not prompt the user questions unless it's vital. If a user has answered a question before (and the settings are saved) a new installation of the package should not need to ask the same questions again.

The scripts should run in an AmigaOS shell. They should also not output anything.

The .readme file

To provide backward compatibility and taking advantage of what is already de-facto standard a package file is shipped with an accompanying .readme file. This .readme file must also reside in the .aps dir as a file named "control".

The file is used to describe a package's features dependencies, version etc. A list of headers can be found here: APS:Headers

APS:Example readme

Package management tools

Tools should exist for creating packages, installing and removing them and checking their validity. Also somethig that downloads a list of available packages.

Such a tool should make a "mirror" version of the AmigaOS system hierarchy for installing files. This hierarchy should be added to default assigns so that programs reads and writes from it before it goes further down the line.

The client part is divided into three layers. apkg is at the bottom doing the actual writing to a local db keeping track of conflicts, dependencies and such. aps-get provides an interface to common tasks that normally involve many packages and/or listings. In addition aps-get can download contents files that contain package metadata to (aps-get update) which it uses to keep the system upraded (aps-get upgrade) and/or present the user with available packages for download and installation. The contents listings can be fetched from various places and they can be tailored to contain certain categories, authors, file types, using mirror from a specific country etc.

A GUI sits on top of that again translating pointing and clicking to the low level commands.

The low level commands will in the beginning be prototyped using a simple script langauge but might be ported to a lower level language like c later.

apkg - a tool for installing, removing and building .aps files

apkg-install - should use .aps files, unpack them, copy content to aps hierarchy and run postinst. Should accept file pattern and URIs.

apkg-remove - should check internal db for installed files, and remove matching ones, run prerm before deleting files.

apkg-build - should take a dir as a parameter and make a resulting .aps file from it. Should report about missing fields.

aps-get - a tool that interfaces with apkg and lets user install/remove packages and show various information about them.

aps-cache - an alias to aps-get for convinience

Lorraine - a gui tool that fetches a list of available packages, lets you configure levels of interaction, preferred mirror and similar. Ater all it's name after a dog, so you basically tell it to go fetch, and is an Amigan's best friend.