Bug 104134 - RFE: rpmbuild fails on relative %_topdir
RFE: rpmbuild fails on relative %_topdir
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-10 09:57 EDT by Paul Nasrat
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-29 11:03:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Nasrat 2003-09-10 09:57:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
When using a relative topdir (eg when in a temporary rpm build space such as
through CVS), rpmbuild fails.

It attempts to cd /../BUILD which obviously doesn't exist.

It looks to me as if build/parsePrep.c is where this occurs

    /* cd to the build dir */
    {   const char * buildDirURL = rpmGenPath(spec->rootURL, "%{_builddir}", "");
        const char *buildDir;                                                  
                             
        (void) urlPath(buildDirURL, &buildDir);
...

The suspect function is rpmGenPath from rpmio/macro.c

if (root == NULL || *root == '\0') root = "/";

Which looks to be the culprit, I guess either you need to resolve relative paths
to put pwd in front or don't add a /

[paul@enki SPECS]$ rpmbuild --define '_topdir ..' -ba rpm.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.55384
+ umask 022
+ cd ../BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /../BUILD
/var/tmp/rpm-tmp.55384: line 26: cd: /../BUILD: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.55384 (%prep)
 
 
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.55384 (%prep)



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

How reproducible:
Always

Steps to Reproduce:
1. Go to a standard rpm build dir structure, go into SPECS subdir
2. rpmbuild --define '_topdir ..' foo.spec

    

Actual Results:  Prep fails with error as described

Expected Results:  rpm continues to build package normally

Additional info:

It's not in the macro processing:

rpm --define '_topdir ..' --eval='%{_builddir}'
../BUILD
Comment 1 ginnie nuckles 2003-11-06 18:00:11 EST
recieve error building e1000 driver  rpm version rpm-4.2.1-4.2
make: Leaving directory `/usr/src/redhat/BUILD/e1000-5.0.43a/src'
error: Bad exit status from /var/tmp/rpm-tmp.89143 (%build)
Comment 2 Leonard den Ottolander 2004-03-10 10:42:48 EST
I am not so sure we want to be able to use relative paths. WONTFIX?

And ginnie, what kind of a comment is comment 1? It does not seem to
have anything to do with this RFE.
Comment 3 Paul Nasrat 2005-11-29 11:03:58 EST
[pauln@enki SPECS]$ rpm -q rpm
rpm-4.4.2-7.i386
[pauln@enki SPECS]$ rpmbuild --define '_topdir ..' -ba dummy.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.48393
+ umask 022
+ cd ../BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.48393
+ umask 022
+ cd ../BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ rm -rf /var/tmp/dummy-root
+ mkdir -p /var/tmp/dummy-root/var/tmp/symlink
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
Processing files: dummy-1.0-2
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/dummy-root
Wrote: ../SRPMS/dummy-1.0-2.src.rpm
Wrote: ../RPMS/dummy-1.0-2.i386.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.8398
+ umask 022
+ cd ../BUILD
+ rm -rf /var/tmp/dummy-root
+ exit 0

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