Re: Debian package for Alire 1.2.1
Alejandro R. Mosteo
> Something that has been in the back of my mind also since the beginnings of
> the project is that I hope it should be relatively straightforward to
> generate Debian packages from Alire's metadata for someone familiar with
> Debian's Ada policy. If not, I would be interested in knowing about the
> obstacles. It would be great if Alire could give back to Debian, I have
> been a direct or indirect user since many years ago.
Hello.
Alire can probably easily build binaries and pack them into an
installable .deb, with some benefits over tar or zip: alert on
overlaping packages, easy uninstallation, basic dependency handling.
On the other hand, alire’s metadata is not sufficient to generate a
.dsc (source package) ready for distribution by Debian or its
derivatives.
Here are some obstactles.
The 'name' field may clash with non-Ada names in the Debian namespace.
The 'licenses' field does not map each file to its license and years.
The 'depends-on' field cannot be translated automatically, at least
because of the name issue above, and also because some version
restrictions may be specific to the Debian upload number (refining the
source version).
Some packages do not use gprbuild (adasockets).
Some packages generate sources / build C... before gprbuild runs
(ncursesada, gtkada...).
Some packages build documentation (Adacore packages). When possible,
Debian builds/installs documentation and binaries independently.
Debian builds and installs each Ada library twice, for static and
shared links. The two installations may overlap but must be
compatible.
Also, the list of .debs built by a given source package varies.
* executables -> foo
* a library -> libfoo-dev libfoo1
* both -> three packages
* several libraries -> libfoo-*-dev libfoo-*1
In that case, libfoo-a-dev may, or not, depend on libfoo-b-dev.
* several libraries and tools (xmlada)
There is no algorithmic way to decide if the documentation must be in
a separate foo-doc or libfoo-doc debs, or if two sets of executables
must be distributed in separate debs.
There is no general way to write integration tests,
Some files must be removed from the upstream sources before
distribution by Debian (mostly for legal reasons).
Alire manages no Shared Object version as far as I know.
Reply to: