Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: xfsdump
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201779
------- Additional Comments From cattelan(a)redhat.com 2006-08-22 17:45 EST -------
OK, I'll go ahead and review this. The links at the top are the only ones I
could find for the package; is that actually the current version?
First off, it doesn't build due to a lack of ncurses-devel.
Ok added that to the BuildRequires
Once I add that it does build. Here's what rpmlint says:
W: xfsdump symlink-should-be-relative /usr/sbin/xfsrestore /sbin/xfsrestore
W: xfsdump symlink-should-be-relative /usr/sbin/xfsdump /sbin/xfsdump
Indeed, these should be relative symlinks.
Ok fixed these up in the spec file.
(new spec file uploaded)
Plus there are tons of these in the debuginfo package:
W: xfsdump-debuginfo dangling-relative-symlink
/usr/src/debug/xfsdump-2.2.38/dump/inv_stobj.c ../inventory/inv_stobj.c
It seems that rpmbuild doesn't include the "common" directory in the
package for
whatever reason. I don't know how to convince it to do so. I guess that if it
were a big deal you could flatten the links. Unfortunately I don't know whether
it's a big deal or not so I'll have to ask around.
I appears that /usr/lib/rpm/find-debuginfo.sh is not picking up the files.
using vpath vs symlinks would be the right thing to do. Unfortunately
there seems to be some ugly hacks with a .c file picking up a different include file
based on which directory is being compiled. Has to do with getop.h for each command
the c file is common but it picks up different options based on which getopt.h
it finds
in the current directory.
So ya it appears the debug package is not that trivial.
--
Configure bugmail:
https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.