Bug 681359
| Summary: | fedpkg srpm does nothing when output file already exists | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Roland McGrath <roland> |
| Component: | fedora-packager | Assignee: | David Cantrell <dcantrell> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 14 | CC: | dcantrell, dennis, giallu, rhbugs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | fedora-packager-0.5.7.0-1.fc14 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-03-10 03:14:19 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
Roland McGrath
2011-03-01 22:26:48 UTC
Don't attribute to malice that which could easily be attributed to ineptitude (either on my part, or the patch submitter where this functionality came from). There is code that is supposed to work like the old makefile system. It looks at the age of the spec file and compares it to the age of any srpm it finds, and if the spec file is newer it will regenerate the srpm. It will also tell you about it if you run with -v for verbosity, otherwise it (attempts to) acts like a good unix app and doesn't output extra stuff. I suppose this could be taken further and examine the age of any used patches to see if they are newer than the spec too, or if the tarball in use is newer, or it can just go back to unconditionally creating the srpm every single time. I could also add a --force like option that will force the creation regardless of file ages. I think your issue here is that the patch file not the spec file got modified, ergo we didn't notice that something had changed and we needed to regen. As a short term work around, you can touch the spec file and that'll work. I certainly did not intend to imply a perception of malice. I was assuming an honest error in the specification of the feature as gleaned from the old Makefile.common, but did not want to impugn anyone's competence, so I was giving it the benefit of the doubt as an honest intent to do something helpful. In fact, the old behavior was not conditional on timestamps at all, despite being in a makefile. The target of the rule was just the phony target "srpm", not the actual computed *.src.rpm file name. It was even marked with .PHONY, so even if there had been a file called "srpm" touched, it would run the rpmbuild -bs command unconditionally. My issue here was that I repeated the precise workflow that I had done before under the old regime, replacing 'make test-srpm' with 'fedpkg srpm' and not changing another solitary thing about what I did, and it did not behave the same way at all. Alright, I've adjusted the code so that it creates a new srpm regardless. It does log if it is going to overwrite, although it gets somewhat lost in the rest of the output. I'll be pushing it up to a bugfix branch soon. (In reply to comment #2) > My issue here was that I repeated the precise workflow that I had done before > under the old regime, replacing 'make test-srpm' with 'fedpkg srpm' and not > changing another solitary thing about what I did, and it did not behave the > same way at all. I'm not sure what was the difference between 'make srpm' and 'make test-srpm'. However, fedpkg never worked that way, it just won't redo the srpm if present, see https://fedorahosted.org/fedora-packager/ticket/84 When I worked on the patch I actually thought about adding the check for other components (Source and Patch files) but that was a bit harder to do at the same time and then forgot about it. If the behavior in the 'make' world was "let's do it always" then I concur the current solution is best. fedora-packager-0.5.7.0-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/fedora-packager-0.5.7.0-1.fc13 fedora-packager-0.5.7.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/fedora-packager-0.5.7.0-1.fc14 fedora-packager-0.5.7.0-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/fedora-packager-0.5.7.0-1.fc15 fedora-packager-0.5.7.0-1.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update fedora-packager'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/fedora-packager-0.5.7.0-1.fc15 fedora-packager-0.5.7.0-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. fedora-packager-0.5.7.0-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. fedora-packager-0.5.7.0-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. |