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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]