Bug 153078 - --specfile ignores %{_arch} and ignores %ifarch
Summary: --specfile ignores %{_arch} and ignores %ifarch
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-01 12:33 UTC by James Olin Oden
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2005-10-26 22:50:39 UTC

Attachments (Terms of Use)
First pass patch (3.85 KB, patch)
2005-04-04 14:10 UTC, James Olin Oden
no flags Details | Diff
This one works. (4.80 KB, patch)
2005-04-04 15:10 UTC, James Olin Oden
no flags Details | Diff

Description James Olin Oden 2005-04-01 12:33:35 UTC
Description of problem:
When querying a specfile using --specfile, if you also define %_arch this seems 
to be ignored.  Additionally, the %ifarch or %ifnarch declarations in the 
specfile seem to be ignored.

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

How reproducible:

Steps to Reproduce:
1. Query the RH kernel specfile as so:

    rpm -q --define '_arch i686' --specfile --qf '[%{NAME}-%{VERSION}-%
{RELEASE}.%{ARCH}\n]' kernel.spec

Actual results:
Will spit out all sub packages that could possibly be built, and the arch will 
be i386 (provided your on an i386-i686 system).

Expected results:
Only the packages that would be built for the architecture specified, and with 
the specified arch.

Additional info:
In our build system, I use this to figure out what rpms should be spit by 
rpmbuild for a given specfile.  I have worked around the arch issue for a 
while, but recently, I needed to build multiple arch's (x86_64, and ia32e) for 
the same media, and it has become more of a thorn.  I will look into this 
myself, but if anyone has any hints I would graciously take them.

Comment 1 James Olin Oden 2005-04-01 13:04:15 UTC
In build/spec.c::rpmspecQuery(), anyarch is set to one and passed to parseSpec
() for the corresponding argument.  I suspect setting this to 0 (i.e. false) 
will cause the behaviour I want...will test this...but this leads me to believe 
that at some consumer expected it work this way.  I could make this optional, 
but then I would have to change the signature of rpmspecQuery() to a take this 
as an option, or I could add it to the QVA_t structure?  Any thoughts?

Comment 2 James Olin Oden 2005-04-04 14:10:23 UTC
Created attachment 112650 [details]
First pass patch

This patch adds a --target option to query that works like rpmbuilds --target
option.  It does report the correct arch now when querying, but it does not
handle the %ifarch stuff.  That said, at one point I had debug statements in
readLine() and found that it should be doing the right thing, but somehow I
still get all packages.  Any advice would be greatly appreciated.

Comment 3 James Olin Oden 2005-04-04 15:10:42 UTC
Created attachment 112651 [details]
This one works.

Got the answer I should have figured out myself from googling.	Appearantly,
Wanderlei Antonio Cavassin, sent the following patch a long time ago:

   --- rpm-3.0.5/lib/query.c.orig  Sat Oct 28 18:47:45 2000 
   +++ rpm-3.0.5/lib/query.c	   Sat Oct 28 18:47:54 2000 
   @@ -556,7 +556,8 @@ 
	   for (pkg = spec->packages; pkg != NULL; pkg = pkg->next) { 
   -	       showPackage(qva, NULL, pkg->header); 
   +	       if (pkg->fileList != NULL) 
   +		   showPackage(qva, NULL, pkg->header); 
	  }	   break; 

Obviously, this was for a much older rpm, but the concept of checking for a
NULL spec->fileList was the trick.  

So basically, the following things are done in this patch:

   - Add --target option to query.  This drills into QVA_t structure adding a
     target structure.	Uses the same semantics and stratagy as rpmbuild's 
   - If target is specified in the QVA_t struct given specQuery() then 
     the macro environment is cleared and reinitialized for each target is 
     done in build.c.  Also, the packages that have a null spec->fileList are
     not queried.
   - If the target is not specified query happens the same way.
   - some specQuery code was refactored to make it easier to iterate accross 
     multiple specified targets.

Let me know if there is anything I could do to make this an acceptable patch.
Also, Paul, if you like the patch, I will work it into the HEAD.

Comment 4 Jeff Johnson 2005-10-26 22:50:39 UTC
Fixed in rpm-4.4.3-0.20 something.

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