Description of problem: Sub-packages with different versions cause that at the point where find-debuginfo runs %{version} is set to whatever the last Version: tag happened to be in the spec. I believe this is because ${RPM_PACKAGE_VERSION} contains wrong value. This behavior is surprising. If ${RPM_PACKAGE_NAME} can contain correctly the name of main package, why not the ${RPM_PACKAGE_VERSION}? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: ${RPM_PACKAGE_VERSION} contains value of whatever the last Version: tag happened to be in the spec. Expected results: ${RPM_PACKAGE_VERSION} contains version of the main package.
The basic problem is as old as rpm itself and by no means limited to %{version}, the same "last spec tag wins" principle applies to all macros based on spec tags (see bug 555926 for another quirk). The only reason %{name} does not get overridden by sub-packages is that sub-package names are declared by other means than Name: tag. An "easy" workaround would be defining another set of macros, eg "pkg_version" etc for the main package, and then identifying all the million places in rpm and specs and associated tools that need changing for correct behavior... One possibility might be tracking spec tag macro for sub-packages additions and popping them on sub-package end, which would allow existing, reasonable uses (sub-package referring to its own tags via macros) to work while leaving the main package definitions around for the rest of spec processing. In theory this should fix worst of the issues without requiring spec or other tool changing, but whether the theory is workable in practise...
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This was not resolved to my knowledge. Mark, any chance your debuginfo changes would resolve this?
(In reply to Vít Ondruch from comment #4) > This was not resolved to my knowledge. > > Mark, any chance your debuginfo changes would resolve this? Sorry no. Not directly. All my changes do is make it so that different versions/arches of the -debuginfo subpackage don't conflict on the file-level.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
Fixed upstream now: https://github.com/rpm-software-management/rpm/commit/ccdb1aa5c675d917b1ba8d026c44fd95bab79e6c
Fixed in rawhide/F27 now as of rpm >= 4.13.90.