Bug 728812

Summary: --installdeps weirdness with --buildsrpm
Product: [Fedora] Fedora Reporter: Jack Perdue <ss>
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: mebrown, williams
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-21 18:06:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
test .spec file which uses %{rhel} tag to determine BuildRequires stuff (and bug with --installdeps) none

Description Jack Perdue 2011-08-07 22:01:20 UTC
Created attachment 517073 [details]
test .spec file which uses %{rhel} tag to determine BuildRequires stuff (and bug with --installdeps)

Description of problem:

--installdeps seems to ignore the macros for the target environment it is loading dependencies for and seems to use the macros from the environment the SRPM was built from (somehow...)


Version-Release number of selected component (if applicable):
mock-1.1.10-1.fc14.noarch
mock-1.1.12-1.fc14.noarch


How reproducible:
Seen this on Fedora 14 i386 and x86_64


Steps to Reproduce:
1. download the attached foo.spec which has the following bit:

%if 0%{?rhel} == 5
BuildRequires: IneedRHELfiles == %{?rhel}
%endif

2. mock -r epel-5-i386 --buildsrpm --spec foo.spec --source /dev/null

3. mock -r epel-4-i386 --installdeps /var/lib/mock/epel-5-i386/result/foo-0-1.src.rpm
                      and
   mock -r epel-6-i386 --installdeps /var/lib/mock/epel-5-i386/result/foo-0-1.src.rpm
  
Actual results:

Error: No Package found for IneedRHELfiles = 5
(for both 4 and 6)

Expected results:

Error: No Package found for IneedRHELfiles = 4
                      and
Error: No Package found for IneedRHELfiles = 6


Additional info:

It seems --installdeps is picking up the definition from rhel5 during the --buildsrpm step.  Not sure how.  But that doesn't seem right.  Note that if I do a --rebuild on the SRPM then I get the proper definition of rhel... that is 4 fails to find IneedRHELfiles=4 (instead of 5) and 6 fails to find IneedRHELfiles=6 (instead of 5) (i.e. I get the "Expected results:" instead of the "Actual results:" above).

Comment 1 Jack Perdue 2011-08-07 22:07:23 UTC
Correction... under "Expected results:"... when using the --rebuild option for epel-6 I get:

  Error: No Package found for bar-6

not 

  Error: No Package found for IneedRHELfiles = 6

which _is_ what should be expected from --installdeps given the .spec attached (i.e. it _should_ fail on IneedRHELfiles=4 on 4 and bar-6 on 6... not IneedRHELfiles=5 for both).

Comment 2 Dennis Gilmore 2011-09-22 20:13:28 UTC
those macro definitions are set at srpm time, this is how rpm works. you need to deine things correctly. its the reason why koji makes the srpm in the target environment before installing deps. because there can also be arch specific buildrequires its just how rpm works. mock could rebuild the srpm after initing the chroot, before working out the deps.

Comment 3 Jack Perdue 2011-12-21 18:06:34 UTC
OK... my misunderstanding.  

I always thought the tools like this parsed the .spec file inside the SRPM and then went from there.  After Denni's comment in September I went and enlightened myself and discovered that dependencies are stored in the meta data.

Too bad... I was hoping to save disk space and bandwidth on a repository I had for RHEL4/5 and Fedora 1415/16/rawhide by only uploading one SRPM, since the same .spec file and sources are used for all those platforms.  But since the dependency info is stored in the SRPM metadata (and not parsed from the .spec file), that obviously won't work.

Thanks for the clarification.... closing this bug (and off to rebuild all the SRPMS he threw away).