Problem building 1.7.6 from source RPM on RedHat 8.0 (was: GnuCash 1.7.5 never displays)

[Roland Roberts]

>>>>> "Chris" == Chris Lyttle <chris@wilddev.net> writes:

    Chris> On Sat, 2003-01-04 at 20:22, Roland Roberts wrote:

    >> I had a similar problem with upgrading g-wrap using the source RPM on
    >> gnucash.org.  To get around it, I added this to the %install section:
    >> 
    >> rm -f $RPM_BUILD_ROOT%{_infodir}/dir
    >> 
    >> The problem is the %post instruction runs install-info which adds an
    >> entry to %{_infodir}/dir or creates the file.  The problem is that for
    >> building the RPMs, it really shouldn't do that.  I don't know enough
    >> about writing RPM specs to have a good suggestion for either of these
    >> problems.

    Chris> FTR here roland, the above install-info command is taken
    Chris> straight from the official redhat rpm spec file for
    Chris> gnucash. This is not the problem you're having.

    Chris> I'm probably gonna give you an answer here you may not
    Chris> like, but you're the second person I've seen with problems
    Chris> stemming from an 'upgraded' 7.2 system. I may be wrong
    Chris> about what you're done here, but I'm assuming that when you
    Chris> found you couldn't get things to work on RH 7.2 you did an
    Chris> upgrade to 8.0 instead of a clean install of 8.0. The
    Chris> problem with this approach is if things are broken on your
    Chris> 7.2 system, you may well retain some of the brokenness in
    Chris> your upgrade.

Sorry for quoting so much, but I've left this idle for a while and
thought it would be helpful to bring everyone back up to speed.

I've finally gone back and had another look at this after running into
the same problem for multiple packages.  I posted on the redhat
mailing list and got a response which referred me to this URL:

    http://www.rpm.org/hintskinks/unpackaged-files/

This is apparently (at least partially) an RPM 4.1 spec-file issue.
RPM 4.1 no longer likes installed but unpackaged files unless you
explicitly tell it otherwise.

It would appear, from the above URL, that my "rm -f ..." hack was in
fact the right solution in this case.

roland
-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland@rlenter.com                            6818 Madeline Court
roland@astrofoto.org                           Brooklyn, NY 11220