https://bugzilla.redhat.com/show_bug.cgi?id=1293100 --- Comment #10 from Michael Schwendt <bugs.michael@xxxxxxx> --- It is not needed to *manually* update spec files for simple updates, such as when replacing source tarballs. Tools like rpmdev-bumpspec handle several normal versioning schemes including Fedora's pre-release and post-release schemes, provided that the Release tag is not flooded with macros. $ rpmdev-bumpspec -V test.spec test.spec -1%{?dist} +2%{?dist} If a versioning scheme cannot be recognised, the tool would perform a minor release bump only at the very right side of the Release tag: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches > postrelease Releases start at 1, however. The 0 is for pre-releases and remains untouched even during updates, since it's a prefix, and the number right of it would be increased as long as a pre-release is packaged: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages > Tarantool naming convention is ${major}.${major}.${minor}-${patch}, > e.g. 1.6.7-155 or 1.7.1-140. Mapping from upstream versioning to RPM package versioning is not always easy. A patchlevel in an upstream versioning scheme is not unusual. However, the dash in ${major}.${major}.${minor}-${patch} is arbitrary and could also be replaced with a dot. Theoretically, in this case, there's nothing wrong with a direct mapping to %version and %release and making ${patch} the most-significant %release value of the RPM package, provided that the update/upgrade path will not be violated (and newer builds will always replace older ones). Let's not forget, though, in a package collection there are activities like automated mass-rebuilds and rebuilds done by other packagers, if compilers or build/runtime dependencies change. If there's no real release number in the spec file, it can lead to increasing ${patch}, because neither tools nor people would know that ${patch} is special and is not the build release number as in thousands of packages. In other words, there can be multiple builds of the same patchlevel release of your software. In the package collection, it is %release (if you don't touch %epoch and %version) that decides which build is newer, and not ${patch}. > tarantool_1.6.8.284.spec https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_File_Naming Plus, somewhat ironically, here you write 1.6.8.284 and not 1.6.8-284. ;-) > # > # Disable stripping of /usr/bin/tarantool to allow the debug symbols > # in runtime. Tarantool uses the debug symbols to display fiber's stack > # traces in fiber.info(). > # > %global debug_package %{nil} If I were you, I would ask about that on packaging@ list. Perhaps there's a way to disable stripping while keeping the -debuginfo package generation. Without -debuginfo packages you lose features like ABRT based backtrace generation and problem reports: https://fedoraproject.org/wiki/Packaging:Debuginfo -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review