Bug 457678
| Summary: | It's possible to include a different spec in the srpm than the one used in build | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vasile Gaburici <gaburici> |
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | jnovy, n3npq, pnasrat |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-07-14 14:34:17 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: | |||
|
Description
Vasile Gaburici
2008-08-03 12:14:02 UTC
Sure. recursion at N+1 is different than recursion at N in general. IOTW, the recipe used to produce a SRPM at stage N is not (in general) the same as the included spec file at N+1. Furthermore, even if the spec files were identical, recursion (as in rebuilding) is not guaranteed because of the large amount of additional configure information. Checking digest (or other content verifier) on spec files will never guarantee that the N -> N+1 build succeeds. But yes, I understand your expectations. (In reply to comment #1) > Sure. recursion at N+1 is different than recursion at N in general. IOTW, the > recipe used to produce a SRPM at stage N is not (in general) the same as > the included spec file at N+1. > > Furthermore, even if the spec files were identical, recursion (as in > rebuilding) > is not guaranteed because of the large amount of additional configure > information. > Checking digest (or other content verifier) on spec files will never guarantee > that the > N -> N+1 build succeeds. > > But yes, I understand your expectations. I'm afraid you misunderstood them a bit. I'm not expecting a guaranteed rebuild. What I'm arguing for is (a bit more) atomicity of the build process w.r.t. to the files that get included in the srpm: {sources, patches, spec}. On a snapshotting file system you could easily fetch exactly the {sources, patches, spec} file versions that started the build and include those in srpm if/after the build succeeds. Since you don't normally have the luxury of snapshotting file system, the fallback (that doesn't involve changes to build process) is to print some stern warning if the {sources, patches, spec} differ at the end. An alternative that does alter the build process would be (for -ba) to create the srpm before initiating the build process, then to unpack it in some temp dir, and build the binaries from what was in the srpm. YMMV. (In reply to comment #2) Forgot to add that checking anything but the spec at the end is overkill since the other stuff not likely to get changed, which is why I didn't mention it in the initial report. Checking the spec at the end is similar to a rpmlint check; it won't guarantee that stuff won't break, but will flag some accidental edit while the build is in progress. Besides, computing a hash on the spec file hardly takes any time... Sure hashes are easy to generate. The issue is when/how the "reference" and the "produced" spec file digest gets compared. You could already build from a *.src.rpm (which verifies the digest), and look at the produced *.src.rpm (which would verify the included spec file). Note that a snapshot file system is not an available solution to rpm. Note also that its not just spec files that can change. If preload runs against just built libraries, then the libraries will be changed from what was built, and can/will cause binary rpm packaging issues. There's certainly no reason not to attempt to solve all these problems, but I'm not sure that rpm is the place to do it, and the incidence is small enough that "Don't modify the spec file while building the package." is perhaps gud enough (once you understand the issue). This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |