Hello,
If you want to do some pre-release version of package and you use following version line for example:
Release: %{?prever:0.}3%{?prever:.%{prerpmver}}%{?dist}
the rpmdev-bumspec sub-optimally updates the Release to:
Release: %{?prever:0.}3%{?prever:.%{prerpmver}}%{?dist}.1
I know that there is support for several variables [1], such as release or baserelease, so you can use:
%global release 3 Release: %{?prever:0.}%{release}%{?prever:.%{prerpmver}}%{?dist}
However, my proposal to improve packaging guidelines to document this feature [2] was rejected. Would it be possible to improve rpmdev-bumpspec to handle the above mentioned scenario without use of some variables?
Thank you in advance.
[1] https://fedorahosted.org/rpmdevtools/browser/rpmdev-bumpspec#L47 [[BR]] [2] https://fedorahosted.org/fpc/ticket/164
I'm not too thrilled about the idea, mainly because this stuff is already pretty hairy, and doing something like this would make it even hairier and the tendency can go on forever, and we don't have a regression test suite.
However, I'm not going to reject the idea offhand, will look into patches if someone submits them. No promises, but extra points for including a test suite in the patch.
Much too often, obscure release tags such as
are of questionable benefit or are evidence of an underlying problem. The author of such spec files touches multiple custom (!) macros when upgrading from/to a pre/post release version of the software.
rpmdev-bumspec recognizes various pre/post release versioning schemes, such as
Release: 0.3.alpha1%{?dist}
and would increase them correctly. The author of such spec files could simply write something like
%global tarver 2.0-alpha1 Version: 2.0 Release: 0.3.alpha1%{?dist}
and also the step from 2.0-alpha1 to 2.0 final would be easy and clear.
Metadata Update from @mschwendt: - Issue close_status updated to: None
The proper fix for this is to move the weird upstream versioning data out of Release and back into Version, where it belongs.
Release
Version
I had attempted to get this to happen in Fedora with my Versioning proposal, but it fell by the wayside for other matters.
I'd much rather not introduce more complex parsing the Release, especially given how difficult this is to test and the lack of tests as it is...
Metadata Update from @ngompa: - Issue assigned to ngompa (was: scop)
Just adding for reference - python-django suffers from this:
Name: python-django %global pkgname Django %global ver 4.1.7 #global pre ... %global real_version %{ver}%{?pre:%{pre}} Version: %{ver}%{?pre:~%{pre}} Release: 1%{?dist} Summary: A high-level Python Web framework
and
steve@fedora ~/p/python-django (rawhide)> rpmdev-bumpspec --new 4.1.7 -c "Test" -u "test@test.com" python-django.spec error: line 6: unclosed macro or bad line continuation error: query of specfile python-django.spec failed, can't parse
steve@fedora ~/p/python-django (rawhide)> git diff diff --git a/python-django.spec b/python-django.spec index be0e99c..0407b57 100644 --- a/python-django.spec +++ b/python-django.spec @@ -3,7 +3,7 @@ Name: python-django %global ver 4.1.7 #global pre ... %global real_version %{ver}%{?pre:%{pre}} -Version: %{ver}%{?pre:~%{pre}} +Version: %{ver}%{?pre:4.1.7 Release: 1%{?dist} Summary: A high-level Python Web framework @@ -136,6 +136,9 @@ cd tests
```
==> https://pagure.io/rpmdevtools/issue/18#comment-494080
Login to comment on this ticket.