fedora-infra / rpmautospec

#239 autorelease and autochangelog inconsistent about skipping commits
Closed: Fixed by nphilipp. Opened by adamwill.

Closed: Fixed
Reopen Issue

Just hit what seems like a rather awkward case in rpmautospec.

I bumped my package version and forgot to update sources. This is something packagers do all the time, just check almost any package changelog. So I have these two commits:

commit 409ab121997598b03cf77a19fddd9219a050fc74 (HEAD -> rawhide)
Author: Adam Williamson <awilliam@redhat.com>
Date:   Fri Dec 10 17:50:26 2021 -0800
    Add missing source tarball
commit be6ef6600e40bed042cc98a70c065a13019b3f1e (origin/rawhide, origin/f35, origin/f34, f35, f34)
Author: Adam Williamson <awilliam@redhat.com>
Date:   Fri Dec 10 17:26:12 2021 -0800
    New release 5.0.0: remove old classes, fix https_url_generic

After be6ef66, I tried to run builds. Those were versioned 5.0.0-1 and, obviously, failed. Then I committed 409ab12 to add the missing sources update.

rpmautospec does not handle this well. The autochangelog side is 'smart' enough to know it should ignore a commit that only touches the sources file, but the autorelease side is not.

Now if I run fedpkg srpm, I get a .src.rpm whose release is -2 (because autorelease 'counts' 409ab12), but whose changelog only goes up to -1 (because autochangelog does not 'count' 409ab12).

It would be best if the autorelease side ignored the same commit that the autochangelog ignored, so the release was still -1. But I could live, I guess, with a useless and spurious bump to -2, if it was consistent between both sides.

Heh, simply bumping the release for each commit is what FESCo asked for :stuck_out_tongue_winking_eye:. But it's really the right thing to do, even if only sources changes, that's no sure sign that the previous commit doesn't have a successful build (e.g. upstream publishing new tarballs of the same version which is thankfully rarer than folks forgetting to upload them in the first place). Anyway, the fix for this would have to be something along the line of "promote the (E)VR of the top-most changelog entry to that of the commit from which is built".

That is a bug then, but in the opposite direction: both autorelease and autochangelog must bump in both cases. I didn't look at the code, but if autochangelog part has some "optimization" to not produce output if .spec wasn't touched, that code must go. There is no way for code to figure out in a general case if a commit is "important" or not. It cannot know if a build failed or not, it cannot know if the change is substantial or not.

EDIT: In other words, after the second commit, the changelog should be:

* … 5.0.0-2
-  Add missing source tarball
* … 5.0.0-1
- New release 5.0.0: remove old classes, fix https_url_generic

Of course that is ugly ;) I think the solution is to use [skip changelog] as discussed in #206. That'll result build -2 with no changelog entry, but I think that's OK. The other option would be to adjust changelog file, but I don't think it's worth the trouble. Users should interpret a build with no changelog entry as a rebuild after the previous changelog entry.
Edited by zbyszek

280 resolves this.
Edited by zbyszek

280 resolves this.

Commit 983df772 fixes this issue
Metadata
None
None
None
None
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.