Bug 139996 - SRPM builds faulty requires if perl symlinked in /usr/local
Summary: SRPM builds faulty requires if perl symlinked in /usr/local
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: 4
Hardware: All Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-19 07:33 UTC by Scott R. Godin
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-20 02:42:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Scott R. Godin 2004-11-19 07:33:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
libbonobo-2.6.2-1.src.rpm will build a faulty binary rpm if a symlink
from /usr/local/bin/perl to /usr/bin/perl is present on the system,
with /usr/local/bin/perl being listed as a 'requires'.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ln -s /usr/bin/perl /usr/local/bin/perl
2. rpmbuild --rebuild libbonobo-2.6.2-1.src.rpm


Actual Results:  $ rpm -qp
/usr/src/redhat/RPMS/i386/libbonobo-2.6.2-2.i386.rpm --requires |grep

Expected Results:  /usr/bin/perl

Additional info:

removing the symlink causes the package to build properly
$ rpm -qp /usr/src/redhat/RPMS/i386/libbonobo-2.6.2-2.i386.rpm
--requires |grep bin/perl

Comment 1 Scott R. Godin 2004-11-19 08:23:20 UTC
corrected typo in summary

Comment 2 Matthew Miller 2005-04-26 15:06:06 UTC
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.

Comment 3 Scott R. Godin 2005-04-27 22:16:32 UTC
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

bumped bug FC version to FC3

Comment 4 Warren Togami 2005-05-24 04:11:40 UTC
I'm sorry, but we cannot realistically support arbitrary non-standard build

Comment 5 Scott R. Godin 2005-05-26 15:10:29 UTC
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 ->


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.

Comment 6 Scott R. Godin 2005-10-10 18:36:53 UTC
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.


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. 

Comment 7 Scott R. Godin 2005-10-10 18:41:45 UTC
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 

Comment 8 Jeff Johnson 2005-10-25 22:23:34 UTC
This bug has lots to do with how you set up a build system, and nothing to do with rpm.

Comment 9 Scott R. Godin 2005-10-27 03:32:57 UTC
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?

Comment 11 Jeff Johnson 2006-01-20 02:42:12 UTC
So don't use rpm if you can't set up a build system properly.

Note You need to log in before you can comment on or make changes to this bug.