Thanks for the comprehensive report, Nicolas. I will make an issue of it in our tracker for future reference.
On Thu, Feb 8, 2024 at 6:34 PM Nicolas Boulenguez <nico...@debian.org> wrote: > 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. > >
