It's really getting to the point we are going to need a package manager so we can eventually do live updates. Let's talk what we want out of a APM and how the objectives should be worded.

Perhaps use dates of packages instead of version numbers?

Biggest thing I want to see, deps handling for install or removals.

Option to override the default install location.

APM should be arch aware.

Dammy

First of all we should have a main rep where we can search and download APM files of available software, then I think we should have something like

> APM install mylittleproggy.APM
> APM update mylittleproggy.APM
> APM remove mylittleproggy.APM

We should define the APM format first, we could have for example something like this:



then we should have a software database for the installed software with records like:


we should have an "installed-files" database too, in order to delete files when no apps need then anymore, something like:


When we copy a new file <ReferencesCount> will be increased, when we remove it, decreased. When the last uninstallation process "see" that the counter is 1 will remove the file from the system.

This is only a 5min hope it will help

A while ago I wrote a simple example of XML for an hypothetic package manager that used to contain pretty much all of the features you were talking about.

It was supposed to be put in a zip/lha/rar/whatever archive and read by an installer.

I'll have to double check my pc at home as soon as I'm back in Milano (now I'm in Orbetello to my parent's house) and I'll post the whole thing: I'm sure many can do what I wrote but, hey... maybe it'll simplify someone's life.

Anyway: planning the behavior and features of a package manager is quite of a complex task... more than it is to actually write the code. Dependencies and system updates are very delicate subjects.

I'll keep you posted as soon as I have my old writings.

Federico

Quote:

I agree! When I started to read this thread I thought immediately to a XML-based package standard.

Maybe a compressed archive which must contain some XML descriptors with mandatory and optional values (eventually overridable) and a package manager able to handle these files and keep track of installed software/libraries and dependences.

Amiga software management is so simple that I think it shouldn't be a difficult task.

Ciao!

TAD

Agree! Time to start new Bounty :)

For Damo ..

Heres a quick draft ..

------------------------------------------------------------
AROS Package Format and Management Tools

Provide a working environment for installing, updating and maintaining Packages on AROS platforms

Package File Format
###################

Provide a suitable "Package Format" for installing and distributing AROS software. You will neeed to provide a means for storing all a packages necessary components in a single file preferably using a standard archive file format (possibly with a custom file name extension) - which must be suitable for use withing AROS.

You should provide means for packages to describe themselves, and for them to handle scripts necessary for the Package Manager and Installer to correctly utilise the packages as described below. You must idnetify and document all the components necessary to make packages work as intended.

Packages must be provided using a namespace suitable for multiple architectures and versioning..

i.e

<package>-<version>-<aros architecture>.<package format extension>

AROS-1.0-pc-i386.apm

Package Manager
###############

Must be able to check installed Packages on an AROS system (#1) and allow users to upgrade from online sources (#2) or localy stored packages. Package Installation will involve Package Manager retrieving the correct packages (or opening on disk ones where applicable), extracting them as necessary, and passing the correct scripts to the AmigaOS/AROS Installer.

Users must be able to Install, Uninstall and Validate Installations using the Package Manager.

Dependencies for packages should be handled by the Package Manager but processed via the Installer


Package Repository
##################

Implement and document a working repository for AROS software which can be utilised by the AROS Package Manager to upgrade/install components on an AROS platform.
(#2)

Packages must be identifiable for a particular platform, installable via the package manager, and should be available via applicable software categories.

Package Installation (Installer)
################################

By providing a Front end to or by updating Installer itself, enable the Installer to handle the scripts used by the AROS Package Manager. It must be able to Check Dependencies, Install, Uninstall and Validate a Package installation (check the components are correctly installed) via standard AmigaOS style Installer scripts.

#1 preferably by storing information about installed packages in a database
#2 preferably using a distributed technology such as torrents

Quote:

I disagree here. One of the biggest gripes I have with the linux package managers is the dependency on a db. If your db breaks all your information is lost about installed packages.
We should have a mechanism where a db can be used as a cache but all the information is also available in the package directory (that is found by the environment variable). This way the DB can be rebuild if the db breaks.

Also I would like to have KISS (keep it simple stupid) as one of the requirements of the AROS package system, e.g. it should be as small as possible to do just the task it needs to do (another gripe with the linux package managers).

Also I would like the update mechanism not be reserved only for apm packages but also be usable by programs that use their own installation script.

greets,
Staf.

I hate package managers! All of them. I might get flamed for this, but this is moving away from one of the core ways of managing Amiga software.

It encourages scattering files and not knowing your system and its files. However, the actual app needs to be kept in the same location. Amiga-like?

Linux is limited by package management because there is more than one type, and because commercial apps and fringe apps end up frozen out of the 'preferred' way of installing software. Adding repositories is a kludge, and you get warnings that installing unofficial software might stop things working. Hardly friendly.

OS X does this in a much more Amiga-like way than Linux. Multiple versions of frameworks can be installed, and app bundles have a standardised layout so they still appear like a binary. Editing a XML config file would be all that's needed to point to the correct library or datatype version if the developer doesn't update the software.

Has the implications of this been serious thought about? Doing this before AROS has many apps or is entirely usable is setting a bad precedent IMHO. Thanks for listening.

Chris

Quote:

A good start would be an OS update manager only. From memory, it was never easy updating the old Amiga OS: always a mish-mash of file copying, overwriting and re-doing custom settings.