Bug 56420 - rpm syntax appears to only work when jumbled in an illogical order
rpm syntax appears to only work when jumbled in an illogical order
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-17 01:54 EST by ctolley
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-17 01:54:21 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 ctolley 2001-11-17 01:54:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90)

Description of problem:
Trying to recompile a SRPM with a specific --target resulted in some odd 
errors.  I had to reverse the order of the commands to make it behave as 
it had in the past.

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


How reproducible:
Always

Steps to Reproduce:
1. Obtain SRPM and do a --rebuild with --target option or attempt to 
rebuild a spec file with --target option
2. Read errors and scratch head in confusion
3. Reorder syntax until you get the desired results (compiling your source)
	

Actual Results:  Previously, performing something along the lines of:

rpm --rebuild package-version.src.rpm --target i686

would result in the building of the package as intended.  Now, this 
results in the error:

error: cannot open i686: No such file or directory

Even reordering to something like:

rpm package-version.src.rpm --target i686 --rebuild

Building target platforms: --rebuild
Building for target --rebuild
error: File package-version.src.rpm does not appear to be a specfile.

This lead me to try installing the src.rpm with -i and doing a -ba against 
the spec with --target i686 in pretty much the same order as the last time:

rpm package.spec --target i686 -ba

which produces:

Building target platforms: --ba
Building for target --ba
Building target platforms: --ba
Building for target --ba
error: failed to stat /usr/src/redhat/SPECS/i686: No such file or directory

(yes, it returned --ba, not -ba)

So I tried:

rpm -ba package.spec --target i686

which gave me:

Building target platforms: package.spec
Building for target package.spec
error: failed to stat /usr/src/redhat/SPECS/i686: No such file or directory

In desparation, I decided to order things in a way that made no sense (at 
least to me, personally):

rpm -ba i686 --target package.spec

And, surprisingly, this worked exactly as I wanted.  It compiled my source 
with a target architecture of i686.  Why did I have to specify the 
architecture target before the --target option?  Totally confusing.

Expected Results:  Why the massive deviation from the order of the command 
syntax, and if it was intended, why wasn't it reflected accurately in the 
man page?  The man page specifically instructs you as follows:

rpm {-ba|-bb|-bp|-bc|-bi|-bl|-bs} [build-options] SPECFILE ...


and under "BUILD-OPTIONS", it says:

--target PLATFORM

Please return rpm to it's previous, logical, syntax flow.  Specifying the 
value of an option before the option shouldn't be correct.  If this was 
intended, please amend the man pages to reflect the changes.

Additional info:

Running RedHat 7.2 with all updated errata packages.  My RPM version is:

rpm-4.0.3-1.03
rpm-python-4.0.3-1.03
rpm-devel-4.0.3-1.03
rpm-build-4.0.3-1.03
popt-1.6.3-1.03

Other system info as follows:

Compaq Proliant 1850R
Dual Pentium III (Katmai) 500MHz
640MB RAM
2.4.9-13smp #1 SMP Tue Oct 30 19:57:16 EST 2001 i686 unknown
Comment 1 Jeff Johnson 2001-11-19 09:40:03 EST
Invoke rpmbuild, not rpm. The build modes of rpm moved
to a helper binary 1.5 years ago.

The "massive deviation" comes from using popt aliases
to rexec the helper binary. That works well enough for
legacy compatibility, but not for production work.

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