Bug 728812
| Summary: | --installdeps weirdness with --buildsrpm | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jack Perdue <ss> | ||||
| Component: | mock | Assignee: | Clark Williams <williams> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 14 | CC: | 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: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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). 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. 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). |
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).