fedora-infra / rpmautospec

#271 Version change detection broken when version is repalced by %fedora macro
Closed: Invalid by churchyard. Opened by churchyard.

Closed: Invalid
Reopen Issue

I am running Fedora 35. Consider this spec chunk:

Name:       fedora-obsolete-packages
# Please keep the version equal to the targeted Fedora release
Version:    38
# The dist number is the version here, it is intentionally not repeated in the release
%global dist %nil
Release:    %autorelease

Now, fedpkg --release rawhide verrel reports fedora-obsolete-packages-38-13.

After this change:

Name:       fedora-obsolete-packages
# Let's keep the version equal to the targeted Fedora release, or 0 otherwise
Version:    %{?fedora}%{!?fedora:0}
# The dist number is the version here, it is intentionally not repeated in the release
%global dist %nil
Release:    %autorelease

Now, fedpkg --release rawhide verrel reports fedora-obsolete-packages-38-1 instead of fedora-obsolete-packages-38-14.

However, when the original version matches my Fedora version:

Name:       fedora-obsolete-packages
# Please keep the version equal to the targeted Fedora release
Version:    35
# The dist number is the version here, it is intentionally not repeated in the release
%global dist %nil
Release:    %autorelease

Replaced with:

Name:       fedora-obsolete-packages
# Let's keep the version equal to the targeted Fedora release, or 0 otherwise
Version:    %{?fedora}%{!?fedora:0}
# The dist number is the version here, it is intentionally not repeated in the release
%global dist %nil
Release:    %autorelease

The release is correctly incremented in fedpkg --release f35 verrel. But it is also incremented in fedpkg --release rawhide verrel where in fact it should be set to 1.

I suspect the machinery that detects the version does not account for macros set from the command line.

Hmm, I’d really like rpmautospec to support this use case but with the way past EVRs are computed, I don’t see how this can work (reliably):

  • The spec file is pre-processed in the context of either fedpkg locally or the koji builder when building the SRPM which is then built by mock.
  • Even if the koji plugin or fedpkg passed the right value for %fedora to rpmautospec(*) so it can set it for processing, rpmautospec would still never know when the version was bumped, as the macro would apply to all previous commits that used it, i.e. all the way back until a hard-coded version was used. The more complicated prototype algorithm maybe could have accommodated that (because it have retrieved info about past builds through git tags), but the simplified version which FESCo asked us to implement is only aware of changes to the spec file itself.

*: Big "if" here, koji builders don’t really have a notion of the OS version they're building a package for, only about the build target and the associated tags which place a certain set of packages into the build root which in turn define the macros used in building the package.

Metadata Update from @nphilipp:
- Issue tagged with: Discussion

Commit c4732bfc relates to this ticket

Metadata Update from @churchyard:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)
Metadata
None

Discussion

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.