This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 789330 - rpmdev-bumpspec is confused on mysql-workbench spec file
rpmdev-bumpspec is confused on mysql-workbench spec file
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rpmdevtools (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-10 08:03 EST by Petr Pisar
Modified: 2013-12-16 15:31 EST (History)
3 users (show)

See Also:
Fixed In Version: rpmdevtools-8.4-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-10 02:31:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Spec file exhibiting this problem (13.91 KB, text/x-rpm-spec)
2012-02-10 08:03 EST, Petr Pisar
no flags Details
proposed fix (1.92 KB, patch)
2012-09-10 08:13 EDT, Michael Schwendt
no flags Details | Diff
Don't bump Release tag lines that are affected by a bumped macro definition already. (2.73 KB, patch)
2013-11-04 08:12 EST, Michael Schwendt
no flags Details | Diff

  None (edit)
Description Petr Pisar 2012-02-10 08:03:57 EST
Created attachment 560891 [details]
Spec file exhibiting this problem

Try bumpspec on in mysql-workbench repository on commit d792f17f8dfc616ba2eecd924884ca3526fdb35e:

$ rpmdev-bumpspec -c 'Test' mysql-workbench.spec 

You get this change:

diff --git a/mysql-workbench.spec b/mysql-workbench.spec
index a98892e..a8dab75 100644
--- a/mysql-workbench.spec
+++ b/mysql-workbench.spec
@@ -111,7 +111,7 @@ Summary:        Scripts for managing and administering MySQL servers
 # Not yet published (else will be package separatly)
 # see ext/mysql-utilities/CHANGES.txt
 Version:        1.0.3
-Release:        0.%{mw_version}%{?dist}.%{mw_release}
+Release:        0.%{mw_version}%{?dist}.%{mw_release}.1
 
 BuildArch:      noarch
 BuildRequires:  python-devel >= 2.4
@@ -257,6 +257,9 @@ update-desktop-database &> /dev/null || :
 
 
 %changelog
+* Fri Feb 10 2012 Petr Pisar <ppisar@redhat.com> - 5.2.37-4
+- Test
+
 * Wed Feb  8 2012 Toshio Kuratomi <toshio@fedoraproject.org> - 5.2.37-4
 - Remove the python-sqlite2 dep as mysql-workbench will work with sqlite3 from
   the stdlib


See the changelog header. And this is not everything:

$ fedpkg --dist f18 verrel
mysql-workbench-5.2.37-4.fc18

This is because rpmdev-bumpspec changes second sub-package only and it does not update main package release:

$ grep Release: mysql-workbench.spec 
Release:   %{mw_release}%{?dist}
Release:        0.%{mw_version}%{?dist}.%{mw_release}.1

But fedpkg
Comment 1 Ville Skyttä 2012-02-11 11:51:41 EST
Bumping subpackage releases is now implemented in upstream git:
https://fedorahosted.org/rpmdevtools/changeset/8ab7ef7

Will look into the other issue later - in the future, please file separate bugs for separate issues for easier tracking.
Comment 2 Fedora Update System 2012-09-02 17:25:02 EDT
rpmdevtools-8.3-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/rpmdevtools-8.3-1.fc18
Comment 3 Fedora Update System 2012-09-02 17:25:54 EDT
rpmdevtools-8.3-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/rpmdevtools-8.3-1.fc17
Comment 4 Fedora Update System 2012-09-02 17:26:48 EDT
rpmdevtools-8.3-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/rpmdevtools-8.3-1.fc16
Comment 5 Fedora Update System 2012-09-03 13:22:31 EDT
Package rpmdevtools-8.3-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rpmdevtools-8.3-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-13208/rpmdevtools-8.3-1.fc18
then log in and leave karma (feedback).
Comment 6 Petr Pisar 2012-09-10 03:02:31 EDT
This is not fixed in rpmdevtools-8.3-1.fc17.
Comment 7 Michael Schwendt 2012-09-10 07:13:27 EDT
> -Release:        0.%{mw_version}%{?dist}.%{mw_release}
> +Release:        0.%{mw_version}%{?dist}.%{mw_release}.1

This is not confusion, but the catch-all fallback that adheres to the Fedora Packaging Guidelines. Bumping the least significant portion of Release is the safe thing to do in such as case:

  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches

The script would have to become much more complex to try to guess what all those macros in "Release" do and whether it would be right to bump %mw_version and/or %mw_release, for example.

The subpackage versioning scheme in the attached spec file does not match existing guidelines. It (ab)uses %version = %mw_version to construct some pre-release after the 0. prefix:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

%global mw_version 5.2.37
%global mw_release 4
%global tarversion gpl-5.2.37-src
%global srcversion gpl-5.2.37-src

Version:   %{mw_version}
Release:   %{mw_release}%{?dist}

%package -n mysql-utilities
Version:        1.0.3
Release:        0.%{mw_version}%{?dist}.%{mw_release}
Comment 8 Petr Pisar 2012-09-10 07:48:36 EDT
I have not problem with where you put the number. I have problem that you do not bump the main package.

You do not need to understand the macros. Just find first Release tag before any %package and append `.1' (or increase last digit literal if exists (which is not this case)).
Comment 9 Michael Schwendt 2012-09-10 08:13:33 EDT
Created attachment 611412 [details]
proposed fix

Here's one fix proposal.
Comment 10 Fedora Update System 2012-09-11 20:24:22 EDT
rpmdevtools-8.3-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2012-09-11 20:33:41 EDT
rpmdevtools-8.3-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Update System 2012-09-17 19:49:44 EDT
rpmdevtools-8.3-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Ville Skyttä 2012-09-23 13:38:41 EDT
(In reply to comment #9)
> Here's one fix proposal.

Appears to fix the test case and I didn't notice any regressions, thanks. Could you supply a commit message for the patch and I'll apply it?
Comment 14 Michael Schwendt 2012-09-24 22:09:51 EDT
Hmmm, a commit message for a fix like that could be: Really bump all Release values in spec file, either as recognized or via fallback.
Comment 15 Ville Skyttä 2012-09-25 11:10:03 EDT
Thanks, pushed.
Comment 16 Fedora End Of Life 2013-01-16 19:45:18 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 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, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Petr Pisar 2013-01-17 08:05:10 EST
I still don't get updated release string at main package. Tested with rpmdevtools-8.3-1.fc17.noarch on specfile attached in this bug report. It does not touch the Release string of main package.
Comment 18 Michael Schwendt 2013-01-17 08:26:23 EST
rpmdevtools-8.3-1 cannot fix it, because it has been released before the patch has been applied upstream: https://fedorahosted.org/rpmdevtools/browser
Comment 19 Fedora End Of Life 2013-07-04 02:36:23 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 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, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 20 Petr Pisar 2013-07-04 07:35:22 EDT
Still issue in F18.
Comment 21 Fedora Update System 2013-10-07 17:40:09 EDT
rpmdevtools-8.4-1.fc20,devscripts-2.13.4-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rpmdevtools-8.4-1.fc20,devscripts-2.13.4-2.fc20
Comment 22 Fedora Update System 2013-10-09 10:16:28 EDT
rpmdevtools-8.4-1.fc20, devscripts-2.13.4-2.fc20 has been pushed to the Fedora 20 testing repository.
Comment 23 Fedora Update System 2013-10-19 02:51:19 EDT
rpmdevtools-8.4-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rpmdevtools-8.4-2.fc20
Comment 24 Michael Schwendt 2013-11-04 06:41:43 EST
In the current ''bad use of "Dist Tag" in some packages of rawhide'' thread on devel@ list, I've learned that the fix for this bug caused unwanted breakage.

It bumps all release values (so subpackages with own Release tags are affected, too), but as a side-effect it bumps values in _competing_ places. For example:

  %global baserelease 5
  Release: %{?rhel:0.}%{baserelease}%{?dist}

It bumps both lines, because there is no method that determines whether subpackages are involved:

  %global baserelease 6
  Release: %{?rhel:0.}%{baserelease}%{?dist}.1

That's harmless, but a superfluous least-significant bump.

I'll be necessary to revise the patch.
Comment 25 Michael Schwendt 2013-11-04 08:12:13 EST
Created attachment 819145 [details]
Don't bump Release tag lines that are affected by a bumped macro definition already.
Comment 26 Michael Schwendt 2013-11-04 08:18:30 EST
One minor weak spot that remains is if a packager uses several "release" macros with a different prefix (whether for subpackages or whatever), e.g.

  %global release 5
  %global baserelease 2

and in the actual Release tag one could not search for '%{release}' because of multiple ways to write that, with/without braces, with '?' prefix, ...
Comment 27 Fedora Update System 2013-11-10 02:31:08 EST
rpmdevtools-8.4-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 28 Ville Skyttä 2013-12-16 15:31:36 EST
I didn't notice comments 24-26 until now, prompted by bug 1043269.

Patch from comment 25 applied in git, but unfortunately kernel.spec is apparently exactly the remaining weak spot :(

Note You need to log in before you can comment on or make changes to this bug.