Often when doing package reviews I find a package that needs some hack in order to get rpmbuild to build a complete debuginfo package. Some of this relates to passing the proper compiler flags and making sure the package doesn't strip its own binaries, which I think is necessary, but occasionally rpmbuild needs the source to be moved around in the build tree, or it needs symlinks flattened or somesuch.
These are just hacks to work around rpmbuild deficiencies, and I can understand if packagers are reticent to clutter up their packages for something of unknown value. So, how important is it to have a proper debuginfo package? How much hacking is permissible or necessary in order to achieve that goal? Is an incomplete debuginfo package (that contains, say, the striped debug information but is missing some or all of the source code) still useful, or would it be better to have none at all?
- J<
Jason L Tibbitts III wrote:
So, how important is it to have a proper debuginfo package? How much hacking is permissible or necessary in order to achieve that goal?
I think these are questions best answered by the maintainer/reviewer (and possibly upstream). The easy answers are: tiny hacks -> do it many hacks/patches -> probably not worth it It's defining the line between the two that's tricky.
Is an incomplete debuginfo package (that contains, say, the striped debug information but is missing some or all of the source code) still useful, or would it be better to have none at all?
Something is certainly better than nothing.
-- Rex
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> Something is certainly better than nothing.
Is it really? I don't know how to use debuginfo packages, so I don't know if there's any point to having them if they're not complete.
Obviously we know that a debuginfo package with no files should be disabled, so what needs to be there before there's any point to enabling it?
- J<
On Monday 21 August 2006 12:26, Jason L Tibbitts III wrote:
Is it really? I don't know how to use debuginfo packages, so I don't know if there's any point to having them if they're not complete.
Obviously we know that a debuginfo package with no files should be disabled, so what needs to be there before there's any point to enabling it?
Enough so that running gdb (gnu debugger) on the application will produce a meaningful traceback. This helps a lot in figuring out where / why an application is crashing. Without a debuginfo package you cannot get this information without recompiling the package and leaving the binaries unstripped.
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Enough so that running gdb (gnu debugger) on the application will JK> produce a meaningful traceback.
So what needs to be there in order for that to work?
I need to be able to superficially inspect a debuginfo package and know whether it has enough stuff in it or not.
- J<
On Mon, Aug 21, 2006 at 11:54:22AM -0500, Jason L Tibbitts III wrote:
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Enough so that running gdb (gnu debugger) on the application will JK> produce a meaningful traceback.
So what needs to be there in order for that to work?
I need to be able to superficially inspect a debuginfo package and know whether it has enough stuff in it or not.
That's very difficult, especially in projects with subdirectories that may redefine CFLAGS/CXXFLAGS w/o the builder noticing. sope/ogo is one nasty candidate for example.
There are some safety pins in debuginfo, IIRC if it's turned on, but the debuginfo turns out empty the build will fail. That's how it gets my attention to fix debugging symbols at least :)
On Mon, 2006-08-21 at 19:16 +0200, Axel Thimm wrote:
On Mon, Aug 21, 2006 at 11:54:22AM -0500, Jason L Tibbitts III wrote:
> "JK" == Jesse Keating jkeating@redhat.com writes:
JK> Enough so that running gdb (gnu debugger) on the application will JK> produce a meaningful traceback.
So what needs to be there in order for that to work?
I need to be able to superficially inspect a debuginfo package and know whether it has enough stuff in it or not.
That's very difficult, especially in projects with subdirectories that may redefine CFLAGS/CXXFLAGS w/o the builder noticing. sope/ogo is one nasty candidate for example.
There are some safety pins in debuginfo, IIRC if it's turned on, but the debuginfo turns out empty the build will fail. That's how it gets my attention to fix debugging symbols at least :)
Indeed, debuginfo being empty is about the only giant red warning flag that I'm aware of. :)
~spot
Hi, On 8/21/06, Tom 'spot' Callaway tcallawa@redhat.com wrote:
On Mon, 2006-08-21 at 19:16 +0200, Axel Thimm wrote:
On Mon, Aug 21, 2006 at 11:54:22AM -0500, Jason L Tibbitts III wrote:
>> "JK" == Jesse Keating jkeating@redhat.com writes:
JK> Enough so that running gdb (gnu debugger) on the application will JK> produce a meaningful traceback.
So what needs to be there in order for that to work?
I need to be able to superficially inspect a debuginfo package and know whether it has enough stuff in it or not.
That's very difficult, especially in projects with subdirectories that may redefine CFLAGS/CXXFLAGS w/o the builder noticing. sope/ogo is one nasty candidate for example.
There are some safety pins in debuginfo, IIRC if it's turned on, but the debuginfo turns out empty the build will fail. That's how it gets my attention to fix debugging symbols at least :)
Indeed, debuginfo being empty is about the only giant red warning flag that I'm aware of. :)
May i know if debuginfo packages are really good in terms of let the end user debug applications to check if he is facing any crashes then why not we have separate debuginfo directory also present publicly for download?
Regards, Parag.
On Sunday 10 September 2006 09:51, Parag N(पराग़) wrote:
May i know if debuginfo packages are really good in terms of let the end user debug applications to check if he is facing any crashes then why not we have separate debuginfo directory also present publicly for download?
But they are. :-) Look into /etc/yum.repos.d/fedora-extras.repo the repository is there although disabled by default.
Regards, Parag.
Hi, On 9/10/06, José Matos jamatos@fc.up.pt wrote:
On Sunday 10 September 2006 09:51, Parag N(पराग़) wrote:
May i know if debuginfo packages are really good in terms of let the end user debug applications to check if he is facing any crashes then why not we have separate debuginfo directory also present publicly for download?
But they are. :-) Look into /etc/yum.repos.d/fedora-extras.repo the repository is there although disabled by default.
Oops i did not look into that. I should have checked it before. One more thing there is no separate iso or directory present in install media why so? Does that mean whoever want to use debuginfo packages he must download it from fedora website?
Regards, Parag.
On Monday 11 September 2006 05:07, Parag N(पराग़) wrote:
Oops i did not look into that. I should have checked it before. One more thing there is no separate iso or directory present in install media why so?
Due to disk space constraints and since those packages are seldom needed the compromise was to leave them only on the on-line repository.
Does that mean whoever want to use debuginfo packages he must download it from fedora website?
Yep.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Jason L Tibbitts III -
Jesse Keating -
José Abílio Matos -
Parag Nemade -
Rex Dieter -
Tom Callaway