Bug 728812 - --installdeps weirdness with --buildsrpm
Summary: --installdeps weirdness with --buildsrpm
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-07 22:01 UTC by Jack Perdue
Modified: 2011-12-21 18:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-21 18:06:34 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
test .spec file which uses %{rhel} tag to determine BuildRequires stuff (and bug with --installdeps) (543 bytes, application/octet-stream)
2011-08-07 22:01 UTC, Jack Perdue
no flags Details

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).


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