A-A-P logo     




A-A-P has four main features:

  1. download and install software packages
  2. search for packages that can be installed
  3. a framework for developing software
  4. manage and distribute different versions of packages

At the end is a list of overall features.

The Use cases also provide information about the features. They show what A-A-P can be used for in a step-by-step explanation.

NOTE: At this moment not much has been implemented yet. What is written here are the current ideas of how it's going to work. This may change over time.

1. Installing software

Sometimes it's easy to install software: Download a package and invoke the command to install it. However, this only works when that package was made to fit on your system. Today there are so many different Operating Systems and optional packages that it becomes difficult to decide which package will work on your system, what settings you must use and which additonal packages need to be installed.

A-A-P provides a simple and uniform way to install software on any system. It all starts with a small file, called a recipe, that provides information about where the relevant files for the package can be found. Depending on your OS and your desires, A-A-P will download the required files. This may be another recipe, a Makefile or a zip archive. When a ready-to-run executable is available this is downloaded. But it's also possible to obtain the sources, tweak the settings and compile (remembering the settings for the next version).
For example, for Linux it may get an RPM file and invoke the rpm program with the right arguments. And when this package depends on another package, A-A-P checks if it's already present and is the required version. If not, that package is installed first.

Similar applications exist. For example, the Debian apt-get and FreeBSD ports system. But these only work on one OS. This makes it difficult for developers to create and maintain packages for several systems. And users need to learn a different method for every system they use. A-A-P provides a uniform way, and can still use the OS-specific methods where needed.

The recipe contains all the information that A-A-P needs about the package. It contains rules about how to handle different properties of a system. For example, there might be one generic source archive in a CVS system, a patch that is required for Mac OS on an ftp server, and a check if you installed service pack 6a if you're running Windows NT 4.0.

When installing software requires intermediate files, A-A-P will take care of cleaning up afterwards. A-A-P also includes security features and tests to verify that the software was installed as intended, without side effects.

It should also be possible to use A-A-P without an internet connection when the software is located on CD-ROM. In the extreme A-A-P can be used to install a whole system.


2. Finding software

There are many places on the internet to find the latest software you want to use. When A-A-P recipes have been made, you need to be able to find them. A-A-P provides a way to search for recipes by name and by functionality.

Collections of A-A-P recipes will be available on the internet. You can find them on a web site for your Operating System, or use a search engine to locate the one you are looking for. This includes packages which can be handled by a generic wrapper recipe. E.g., if you are running FreeBSD, A-A-P will search the available FreeBSD packages and the FreeBSD ports collection.

For projects that were not made for A-A-P, the user can write the recipe himself. Examples and guidelines are provided to make writing of recipes easy. Common tasks are provided by A-A-P. The recipe can be shared with other A-A-P users and become a wrapper around an existing project.


3. Working on software

Developing open-source software requires the knowledge of a large number of tools. This makes it difficult to help improving an existing project and even more difficult to start one.

A-A-P makes it a lot easier to work on a software project in a distributed environment. The main sources may be obtained from a CVS server, the patches for a port to your system from an ftp server, and additionally you have changed a few things yourself. The recipe describes all this and how to automatically build the program.

For large projects A-A-P provides the possibility to only have those parts local that you are working on. The rest is obtained when needed. You can browse the project to find the source code and documentation that you need. A-A-P knows where to find it.

A-A-P forms a framework in which many tools can work together. Interfaces are specified so that tools can be plugged in easily. You are free to chose the tools that you know and like. For example, you can use your favorite editor to display code you are debugging.

A-A-P provides a system to browse a project to find out how it works. Locate the code that you want to work on, read related documentation. Some parts of the project may be accessed over the internet and/or downloaded on demand.

A-A-P allows others working on the same project to use different tools. This is especially useful if you don't like the "company standard" tools. Two version control systems can be used: One for working together with others and one for personal work. Interfaces to various version control systems are provided.

Automatic configuration for different systems is provided. Like autoconf, but working on many operating systems. A portable script language is used instead of Unix commands. A set of standard checks is provided to make this easier. The same script language can be used in recipes. This replaces the use of system-specific shell commands in makefiles.


4. Distributing software

When you make changes to a project A-A-P provides you with the actions to make a patch and send it to the right place. Or just keep it locally so that you can apply it to the next version. You can do version control without having to know the exact commands for it.

The main problem with working on open source projects is managing all the different versions. Projects often work with a central version control system and many developers who try to get their changes included in that system. A-A-P supports that, but also provides the alternative that individuals can make their own version available. This makes it easy to exchange half-finished ideas and fixes that were not included in the central version yet. You can invite others to have a look at your solution, without the need to create a patch and send it each time you make an improvement.

For maintainers of the central version A-A-P provides tools to package a new version of a project for others to install (with or without A-A-P) and release it to the world. This includes sending (generated) files over the internet to a http or ftp server, uploading generated packages for distribution and announcing the new version in various places. This works similarly to building an application. It can also be used to maintain a web site, for example. "push" distribution is done by providing an interface to existing systems that implement this. Generation of standard packages (e.g., RPM) is automated as much as possible.


Overall Features

  • A-A-P is portable over many systems. At least most Unix variants, MS-Windows and possibly the Macintosh.
  • A-A-P is open source, free software. Most of it is under the GNU GPL. Interfaces and libraries are more free.
  • A-A-P is not a monolitic program. It is made out of separate modules with clear interfaces. Most of the work is done by existing tools.
  • Since network connections are slow and unreliable - and when using a laptop - a local copy of a file is often required. A-A-P caches files, obtains a new version when available and cleans up files that have not been used recently.
  • The more alternatives there are, the more choices a developer has to make. Making all these choices slows down development. Therefore A-A-P provides a preferred set of modules. Many people will be satisfied with most of these modules, but will still be able to use a different module where they have a preference.
  • A-A-P is available in a command-line version and in a GUI version. The command-line version works on a console and over a telnet connection. The GUI version is easier to use, but requires a windowing system.
  • A-A-P maintains a set of preferences. These are global to all projects but local to the user or system. This specifies where specific tools, libraries, documentation files, etc. can be found. This greatly reduces the need to configure a package when building or installing it.
  • English is used in the original code. Provisions are made to add translations through the use of message files.
  • Reliability is considered more important than fancy features. A-A-P is a tool you can rely on.
  The A-A-P pages:
Zimbu award
     Recipe examples
     Aap manual
     Agide tutorial
     Aap version log
     Agide version log
     ported apps
maillists and chat
plan and tasks
     SourceForge pages
     Aap todo list
     Agide todo list
     use cases
     design decisions
tools overview
     script languages
     build tools
     Install tools
     issue tracking
     version control
     browse tools
     various tools

Zimbu! - browse the Keyword Map of
funded by:


Send comments on this page to Webmaster AT            Hosted by SourceForge Logo            Also known as