Bug 2180791

Summary:	Spec file versioning macros
Product:	[Fedora] Fedora	Reporter:	Cristian Le <fedora>
Component:	redhat-rpm-config	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	42	CC:	ajax, carl, ffesti, fweimer, igor.raits, j, maxwell, mhroncok, ngompa13, nickc, pmatilai, sipoyare, torsava
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-06-08 15:40:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Cristian Le 2023-03-22 10:05:51 UTC

This is a reference from fedora packaging committee issue[1]:

> I would like to propose a few helper macros for dealing with version control:
> - Format git tag -> rpm version: e.g. `1.2.3-rc1`/`1.2.3rc` -> `1.2.3~rc1`. This could be detected from python's `packaging.version`[2]
> - Format rpm version -> git tag/free format: e.g. `1.2.3~rc1` -> `1.2.3-rc1`. An interface for this could be: `%{version_format -base 1.2.3 -prerel rc1 -format v{base}-{prerel}}` or if possible more automated `%{version_format -version %{version} -format v{base}-{prerel}}`
> - Detect version from git tag/`.git_archival.txt` similar to `setuptools_scm`. This would be incredibly useful for in-source packaging, but not in dist-gits
>
> These issues arose when trying to make packit be able to parse the version from git tags like v1.2.3-rc1. We can make a custom handling there, but it would be better to have a more standardized way to do this. The best case is to implement these upstream so that these can be used by OpenSuse as well.
> For reference here are a few workarounds that have to be maintained and are inconsistent with each other: bluefish[3], cmake[4]

There is also a proposal for migrating the macro used in rust packaging `%{version_no_tilde}`[5], but this is a more complete, and if it can be introduced here, it could be used from the start of the spec file.

I have also opened up an issue[6] on rpm upstream.

[1] https://pagure.io/packaging-committee/issue/1264
[2] https://packaging.pypa.io/en/stable/version.html
[3] https://src.fedoraproject.org/rpms/bluefish/blob/rawhide/f/bluefish.spec#_2
[4] https://src.fedoraproject.org/rpms/cmake/blob/rawhide/f/cmake.spec#_68
[5] https://pagure.io/fedora-rust/rust2rpm/issue/192
[6] https://github.com/rpm-software-management/rpm/issues/2443

Comment 1 Miro Hrončok 2023-03-22 10:15:04 UTC

It's unclear to me whether you propose to implement this or you would like somebody else to do it. Reimplementing packaging.version in RPM macros might be a tad tricky.

Comment 2 Cristian Le 2023-03-22 10:25:51 UTC

Well. We might need to discuss on how it can be designed, the name of the macros etc, and where should it be first implemented? Upstream, or here first. I think we can update here first to see what roadblocks we can encounter.

I thought rpm was using python, but I see that's not the case, so we would have to manually implement these. Can we use regex, python scripts, C++ functions with dependencies in macros? If so I think I can implement 1 and 2 with some pointers to where to start.

Comment 3 Miro Hrončok 2023-03-22 17:24:15 UTC

If you want to have it in redhat-rpm-config you can implement it in RPM macro syntax or Lua only.

Comment 4 Fedora Release Engineering 2023-08-16 07:12:18 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Comment 5 Aoife Moloney 2024-11-08 10:50:10 UTC

This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
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 EOL if it remains open with a
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 6 Aoife Moloney 2025-02-26 12:53:29 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

Comment 7 Fedora Release Engineering 2026-05-06 11:28:22 UTC

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
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 EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 8 Aoife Moloney 2026-06-08 15:40:04 UTC

Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 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 Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.