Bug#401385: This might not be as easy as I thought...
Ludovic Brenta wrote:
> Hi Kevin,
>
> Thanks for taking all that trouble. The debugging information should
> not go into the package libgnat-4.1, because that's a run-time-only
> package not intended for developers.
That may be true, but developers aren't the only ones who might make
use of these files. Anyone who gets a crash in an Ada application
could get a much better traceback (for filing a bug report) with these
files in place than without.
Independent of the potential issues described below, we should give
some serious thought to including the debugging files with the runtime
package.
It does bloat the package a bit, though.
> Instead, the debugging information should go either to a new package
> (libgnat-4.1-dbg), either into package gnat-4.1, which already contains
> the static library with debugging information as well as the compiler.
>
> Creating a new package is a better long-term solution, because sooner or
> later we'll want to switch to multilib. In a multilib system, we do not
> want to have both libraries and programs in the same package.
OK, I'll be happy to do that if we ultimately decide it's the right
way to go. But see below.
> Are you comfortable editing debian/control.m4 and
> debian/rules.d/binary-ada.mk to add the new package? Then send me a
> patch? If you do that then I'll review and apply your patch into the
> next upload.
Binary-ada.mk is what I was editing to test this to begin with, so
from what I can tell all I need to do is to change the option to
dh_strip to get it to put the debugging files into separate pacakges.
But given that the control file is generated from an m4 master,
changing binary-ada.mk in the required way may be a problem. The
argument to dh_strip will be --dbg-package, and it takes the name of
the target package as its argument. That's a problem because the
package names are generated from the m4 master. Unless binary-ada.mk
is also generated from an m4 master, how do I get the package names to
be correct? If I have to hardcode them (which implies we have to
change their names every time we uprev the version), then there'd be
little point in having an m4-generated control file.
The bottom line is that unless the same variables that are used for
substitution in the m4 control master file are available to
binary-ada.mk, this is going to be much more involved than it would be
if we simply include the debugging data files with their primary
packages (which is what I'm doing right now).
--
Kevin Brown kevin@sysexperts.com
Reply to: