Features
A-A-P has four main features:
- download and install software packages
- search for packages that can be installed
- a framework for developing software
- 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.
top
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.
top
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.
top
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.
top
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.
top
|
