Fix "make rpm" - #172
Conversation
the setuptools version and SPEC_VERSION might not be in-sync, which breaks "make rpm" and "make release-rpm". Let's prioritize the spec-version for RPM builds and VERSION everywhere else. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Lukáš Doktor <ldoktor@redhat.com>
with hardcoded versions we can not distinguish between released or any development or even dirty versions, which could have terrible consequences when reading issues. Let's bring back the "dynamic" versioning but add "fallback_version" to use the hardcoded value in rpm builds. Note the "make rpm" should always use the spec-version, this is deliberate to ensure rpms use spec files while pipy/devel versions use dirty versioning. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Lukáš Doktor <ldoktor@redhat.com>
|
Gladly! Will let you know within a few days. |
| PROJECT=aexpect | ||
| VERSION=$(shell $(PYTHON) -m setuptools_scm) | ||
| VERSION=$(shell $(PYTHON) -m setuptools_scm 2>/dev/null || grep '^Version:' python-$(PROJECT).spec | awk '{print $$2}') | ||
| SPEC_VERSION=$(shell grep '^Version:' python-$(PROJECT).spec | awk '{print $$2}') |
There was a problem hiding this comment.
This line seems repetitive of the one above, how about simply getting SPEC_VERSION first and then retrieving the backup version directly from this variable being already set?
| source-release: clean | ||
| mkdir -p SOURCES | ||
| git archive --prefix="$(PROJECT)-$(VERSION)/" -o "SOURCES/$(PROJECT)-$(VERSION).tar.gz" $(VERSION) | ||
| git archive --prefix="$(PROJECT)-$(SPEC_VERSION)/" -o "SOURCES/$(PROJECT)-$(SPEC_VERSION).tar.gz" $(SPEC_VERSION) |
There was a problem hiding this comment.
So I assume this and the below diff blocks need SPEC_VERSION explicitly? What would happen if the SPEC_VERSION differs from the VERSION here? Would this still be reasonable?
There was a problem hiding this comment.
The previous (hardcoded) version used a fixed version to avoid problems passing it between mock and the repo. To keep this behaviour I added the SPEC_VERSION which is used for rpm targets while keeping it dynamic for the other targets. So different version should result in the RPM force-setting to the SPEC one.
Ideally I'd like to remove the SPEC_VERSION completely, but you claimed it didn't work on your build system.
| [tool.setuptools_scm] | ||
| version_scheme = "post-release" | ||
| local_scheme = "node-and-date" | ||
| fallback_version = "1.8.0" |
There was a problem hiding this comment.
So in some sense we still end up with non-dynamic version, no? Because either we have to update this each time as we would have updated version or we don't update it but get strange cases where higher version might display as lower version which could cause some havoc in deployment pipelines.
2 participants
this is a follow-up after #165 which fixes the Makefile so the "make rpm" works and then contains extra commit to attempt to restore dynamic versioning for pip versions while keeping hardcoded one for RPMs.
@pevogam please try this out I hope it'll work for you as well as for me. My main problem with the current version is that any issue reported will only contain the hardcoded version but we will not know whether it was released, development or even custom dirty version. I'd really like to have some dynamic versioning in-place.