Description of problem: If a file with the output src.rpm name already exists, 'fedpkg srpm' does nothing but exits silently with successful exit code. This is nonobvious, unhelpful, and contrary to the behavior of the old world's 'make test-srpm', which 'fedpkg srpm' is supposed to replace. If I make a botched srpm, then I'll edit one of the constituent patch files and repeat 'fedpkg srpm' to replace the bad srpm with a new one. It doesn't make sense to change the .spec file's Release: field for every time you do this, when the only use of the srpm was local test builds or koji --scratch builds. Moreover, silently doing nothing is the worst kind of noncompliance with a user request. If you are going to obstinately not do what I told you to do, the least you could do is give an error message and exit with nonzero status. Version-Release number of selected component (if applicable): fedpkg-0.5.5.0-2.fc14.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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.