Bug 139996

corrected typo in summary

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

downloaded the FC3 libbonobo src.rpm
added the symlink to /usr/bin/perl as /usr/local/bin/perl
did rpmbuild --rebuild libbonobo-2.8.0-2.src.rpm

results: configure script finds /usr/local/bin/perl and ignores the fact that
it's a symlink, and builds libbonobo against that, and sets it as a requirement

rpm -qp /usr/src/redhat/RPMS/i386/libbonobo-* --requires |grep perl
/usr/local/bin/perl  
perl(Getopt::Long)  

bumped bug FC version to FC3

I'm sorry, but we cannot realistically support arbitrary non-standard build
environments.

So you're saying that some scripts don't assume #!/usr/local/bin/perl in the
shebang line and adding a symlink to the correct location of Perl so that the
scripts run properly with no modification is a bad thing? 

The bad thing is that this causes certain *RPM PACKAGES TO BUILD IMPROPERLY* 

    *AND FAIL*

I'm not asking you to _support a nonstandard perl install_ in /usr/local/bin,
I'm asking you to make sure your package builds properly 

    _for the standard Fedora Core Perl environment_ 

DESPITE the presence of NOTHING BUT A SYMLINK from /usr/local/bin/perl ->
/usr/bin/perl.

...

Other than that ONE symlink to provide clean transition for some third party
script packages to run on the system unmodified, it's a bog-standard FC3 install. 

*laughing* it's a pretty poor system indeed where I have to destroy the symlink
that allows some running scripts to function without modification just to
compile a package.

ran into this again yesterday, when I tried to rebuild the SRPM for xscreensaver 
to add back in some of the missing saver-modules only to have to again delete 
the symlink from /usr/local/bin/perl to /usr/bin/perl. 

Then, today, I spent almost an hour trying to debug why my perl script was 
failing on a localhost-only httpd server I run on this box so I can preflight 
the cgi work I do for my website clients before uploading to their server and 
breaking their forms til I can solve problems. Kept getting "premature end of 
script headers", so I ran the cgi through perl -cT to test for syntax errors.. 
fixed those.. problem still exists. ARGH! couldn't figure it out for the life of 
me til I suddenly recalled that for this client, uploading the cgi to their 
webserver requires that the shebang line point at THEIR /usr/local/bin/perl.

*headdesk*

if httpd can figure out that /usr/local/bin/perl is a symlink to /usr/bin/perl 
and run modules installed ONLY for /usr/bin/perl without problems, surely 
rpmbuild can do the same? 

I've said this before and will say it again: I shouldn't have to break running 
scripts on my server just to recompile a srpm in this manner. 

this is now FC4 by the way -- bog-standard except for additonal perl modules 
installed off of CPAN. I only have ONE perl installed -- the one that came with 
the system. 

changing component to rpm as it is more evident now that the problems stem from 
how rpmbuild is handling the environment, and less upon which SRPM is built by 
it. 

This bug has lots to do with how you set up a build system, and nothing to do with rpm.

Way to go with a comment that says absolutely nothing concrete regarding a 
solution, and yet is worth closing the bug for? 

Build system is a (stock) fedora core install with the addition of one symlink 
from (stock) /usr/bin/perl to /usr/local/bin/perl to allow certain third party 
scripts to run without modification under a (stock) httpd for local 
predeployment testing.

I reiterate: If Apache can handle the fact that Perl isn't under /usr/local, why 
can't rpm? If rpmbuild only works correctly on a build system that's pure as 
driven snow, isn't that just a wee bit fragile for the real world?

So don't use rpm if you can't set up a build system properly.