[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

preliminary thoughts about an ada library debhelper tool


(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

* 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

* 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: