No subject

these developments as much in sync as possible. I made
available - and continue to do so - the ALT buildsystem to
Arno and a few others so that they can make use of the
knowledge thats accumulated in this system over the years.
In fact Arno asked me for our stuff and thats clearly a
good sign:-)

Take for example this tiny problem with the differentiation
of the build- and the target-architecture for RPMs. Some
of you were not able to install the ACT RPMs on an i586
or AMD. Thats a problem we solved nearly a year ago. And a
lot of such tiny details are addressed in the ALT
buildsystem. We have informal results showing us that the
unmodified system can be used to build RPMs on SuSE, Red Hat
and Mandrake and that the resulting  RPMs can be installed
and run on each of the other systems.

AFAIK the ALT RPMs are the only reasonably complex RPMs that
have this feature. If you look at GNOME or KDE, they have
different RPMs for the different distros and I believe this
is close to a nightmare for the people building these
packages.

Nevertheless the ALT packaging has some overall goals that
might not be shared by ACT and therefore we may end up in
two parallel RPM offerings, which is not a bad thing per se
as long as we can make them as compatible as possible.

As Gerd Arlitt pointed out, one of the ALT packaging
features is that we try to offer a whole suite of packages
that is integrated. The suite not only contains ACT software
but also some usefull other packages (Booch components,
(n)curses binding, Tcl/Tk binding, aflex/ayacc, Rapid etc.
etc.). We want to make it easy for programmers to use Ada
on Linux. And this not only means to have the compiler and
related tools, but also reusable libraries and components
that are easy to install. So ALT has definitively a
different scope than ACT.

In the ALT packages there is a common scheme how the
libraries are organized and where the documentation is
stored. Any package automatically installs a link into a
HTML documentation tree so that the ALT RPMs maintain some
automatic HTML documentation index. We made some changes to
GNAT itself to accomodate this integration. So for example
we have an additional default include and objects directory
(additional to the GNAT runtime dirs), we do shared libs as
default and we only support (native) LinuxThreads which are
not fully conforming to the LRM but which are in our opinion
the way to go on Linux.

I hope this makes clear that we are aware of the problems
and that we are addressing them.


Cheers
Jürgen