preliminary thoughts about an ada library debhelper tool
Hello.
(This should only concern library packagers.)
I am interested in writing a native package providing a program in the
Debian helper style, named dh_ada_library.
To respect Debian helper tradition,
* it could be run directly or inserted in the dh sequence
by adding "--with ada-library" to the dh command.
* it would take its input on the command line arguments or from the
file debian/dh_ada_libraries
* it would only affect packages specified with --arch, --indep or
--package options.
* it would handle DH_VERBOSE,--verbose,DH_NO_ACT,--no-act as expected
The arguments would be a list of ".gpr" project files, the same
projects that were used to built the libraries provided by the source
package. As it is common practice to use environment variables in
build project files, it would accept something like "KIND=dynamic
debian/foo.gpr KIND=dynamic bar3.gpr".
Its action could be:
* parse debian/foo.gpr to know the library name, the withed projects,
sources directory, ali files directory, static library path and
linker -l or -L options (~ LDLIBS). This supposes that no other such
linker options are mentioned in gprbuild or gnatmake command line.
We could imagine passing more linker options as environment
variables, but I doubt the added complexity is worth the benefit.
And you gain the same effect with Import_As_List ("LDLIBS", " ") in
the project file.
I think it would be good and possible to ignore the Library_Version
(~ soname) field in the project, so that modifying debian/foo.gpr,
debian/dh_ada_libraries or in a dh_override is not needed when
soversion increases. It can be deduced at next step anyway.
* parse debian/control
"Package: libbar3-dbg" to check consistency
"Package: libfoo32-dev" to guess foo aliversion=32
"Package:libbar3-42" to guess bar3 soversion=42
Deduce the soname.
* install the dynamic library into the library package.
* If it declares its stack as executable, install a lintian override
about gnat using trampolines for exception handling.
* install the dynamic link, static library and ali files and sources
into the -dev package.
Create a system-wide project, including all "-l.*" and "-L.*" linker
options.
* Append
"gnat, gnat-$(gnatgcc --version)"
to "ada:Depends=" in debian/dev_pkg.substvars,
so that debian/control does less depend on soversion, gnat version,
or potential policy changes.
* Append "lib_pkg (= ${binary:Version})" to the same substitution
variable.
* Append "lib$(name_of_withed_project)$(its_aliversion)-dev " to the
same substitution variable for each withed project that correspond
to a -dev package in the same source.
* Same thing for each withed project that does not correspond to a
-dev package in the same source, but is available in unstable.
* Ideally, list all -dev C dependencies from -L -l options, but the
gain seems small compared to the probability of a false guess.
* Append
ada:Depends= lib_pkg (= ${binary:Version)
ada:Recommends= dev_pkg (= ${binary:Version)
ada:Suggest= gnat
to the -dbg package.
* "dh_installdocs --package=lib_pkg"
"dh_installdocs --package=dbg_pkg --link-doc=lib_pkg"
as this operation has a (small) size benefit at no cost.
* "dh_strip --package=lib_pkg --dbg-package=dbg_pkg"
"dh_strip --package=dev_pkg --exclude=path_to_static_archive"
to ensure policy compliance.
* Ideally, add some tests that lintian cannot do as it cannot detect
Ada packages. Detect if a package Build-Depends on gnat and
gnat-X.Y, for example.
I was tempted to add a first step compiling the library, but
- replacing gnatmake/gnat make/gprbuild/whatever upstream uses is not
recommended by Debian policy, when the upstream system can be used..
- Makefiles exist for that.
Would something like that be useful to someone else?
Would someone sponsor the package?
If yes, any other ideas?
Reply to: