Hi,
How about making empty debuginfo packages a build error? I can't think of a reason why an empty one would be a desired result, but empty ones do almost always indicate problems with the build. Arch specific packages that expectedly don't have anything to place into the debuginfo package should explicitly disable it eg. with "%define debug_package %{nil}".
Also submitted as https://bugzilla.redhat.com/249956
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> How about making empty debuginfo packages a build error?
Sure. And I'm having trouble coming up with a situation where a debuginfo containing a single file is OK, since it generally indicates that debuginfo was extracted from an executable but no source was found. (Common for Java packages, at least.) Or is such a stunted debuginfo package still considered useful?
- J<
On Saturday 28 July 2007, Jason L Tibbitts III wrote:
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> How about making empty debuginfo packages a build error?
Sure. And I'm having trouble coming up with a situation where a debuginfo containing a single file is OK, since it generally indicates that debuginfo was extracted from an executable but no source was found. (Common for Java packages, at least.)
Yep, ditto cases where "strip -g" is invoked on the binaries before find-debuginfo.sh does its thing, or the binaries are built without -g which almost always means that $RPM_OPT_FLAGS aren't being used either and at that point useless -debuginfo is no longer necessarily the biggest problem.
Or is such a stunted debuginfo package still considered useful?
I don't think so, at least generally, but detecting it without false positives is harder than the empty debuginfo case. And the Java case is a good example of another problem - I'm not sure we'd want people to disable debuginfo packages because the tools don't support creating sane ones from them yet.
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And the Java case is a good example of another problem - I'm not VS> sure we'd want people to disable debuginfo packages because the VS> tools don't support creating sane ones from them yet.
Actually it's possible to fix the Java packages; you have to move the source so that the scripts will find it. I've been through this on pretty much all of the Java packages I reviewed. (It's been a while since I did one, though.) I've also had to do this with some Perl XS-built packages.
I admit this is nasty, but I've been assuming that we really want proper debuginfo when we can get it.
- J<
On Saturday 28 July 2007, Jason L Tibbitts III wrote:
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And the Java case is a good example of another problem - I'm not VS> sure we'd want people to disable debuginfo packages because the VS> tools don't support creating sane ones from them yet.
Actually it's possible to fix the Java packages; you have to move the source so that the scripts will find it. I've been through this on pretty much all of the Java packages I reviewed. (It's been a while since I did one, though.) I've also had to do this with some Perl XS-built packages.
Ah, good to know. If there's a common pattern how these files need to be moved around or how to generally find a way to do it, could you add some info about it to http://fedoraproject.org/wiki/Packaging/Debuginfo ?
I admit this is nasty, but I've been assuming that we really want proper debuginfo when we can get it.
Ditto.
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> If there's a common pattern how these files need to be moved VS> around or how to generally find a way to do it, could you add some VS> info about it to http://fedoraproject.org/wiki/Packaging/Debuginfo VS> ?
I'm not sure that I even remember how to do it. I guess I could review another Java package, or I could try to find an on-point review.
Here's one: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191014
I note that you've commented in there as well.
- J<
On Saturday 28 July 2007 19:08:03 Jason L Tibbitts III wrote:
Actually it's possible to fix the Java packages; you have to move the source so that the scripts will find it. I've been through this on
Is it not possible to fix the script to find the source files without moving them? Or maybe add an enviroment variable to specify where it should search?
Regards, Till
packaging@lists.fedoraproject.org