https://bugzilla.redhat.com/show_bug.cgi?id=1293100 --- Comment #9 from Roman Tsisyk <roman@xxxxxxxxxx> --- > Don't be so impatient, please? Sorry :) > Amazing. All that to end up with a very simple %version-%release, > How should the git-commands in the spec-file work from outside a git-repo ? This hack is used to automate packaging on Travis CI + Docker + rpmbuild. We actually build packages for **each** git commit without manually changing RPM spec. Current time to deliver is less than 5 minutes. I removed this stuff from proposed spec file. > > cd tarantool-%{version}-%{build_version}-%{git_hash}-src > Upstream build != Fedora package build, so this is asking for trouble. If you > ever needed to specify strict versioned dependencies, it would also get more > complicated than with a plain %release value. > If the %build_version is considered important, look for ways to move it into > %version. Else move it to somewhere at the right side of the Release tag, > where it doesn't have a huge influence on RPM version comparison checks. Tarantool naming convention is ${major}.${major}.${minor}-${patch}, e.g. 1.6.7-155 or 1.7.1-140. ${patch} is the number of commits after tagging a release (git describe --long --always). We usually create and tag a new git branch for a development version after publishing a minor release. Some fixes still can be pushed (backported) to published release if have substantial reasons for that (security fixes, regressions, several drawbacks that affects customers and so on). It is enterprise level of support which we provide for free for anybody. Any user can install crucial bugfixes without need to wait for the next minor release. Of course, this approach increments ${patch} counter for already released version. Strict dependencies on ${patch} is never needed. I carefully checked the wiki page pointed above and found that **postrelease** conception is almost close to our naming scheme. Therefore, I changed naming to use numeric postrelease tag: # ${major}.${major}.${minor}, e.g. 1.6.8 or 1.7.5 Version: 1.6.7 # ${fedora release}.${upstream patch level (postrelease)} Release: 0.540%{?dist} I'm not sure that it is possible to automatically update package in Fedora for each fix, but I would be good at least to upload security fixes and minor releases. > Start with pointing the fedora-review tool at this ticket: > fedora-review -b 1293100 > Unfortunately, in Fedora 23 the tool suffers from the migration to DNF, so some checks take ages compared with Yum. Unfortunately, this tool doesn't work on my rawhide from Docker. :( I uploaded a new version of spec. Spec URL: https://gist.github.com/rtsisyk/8a8d2dcae143d0699e76/raw/ee9e5c49d79d797c62e19b5d57dd59ca7224a22e/tarantool_1.6.8.284.spec SRPM URL: https://gist.github.com/rtsisyk/8a8d2dcae143d0699e76/raw/ee9e5c49d79d797c62e19b5d57dd59ca7224a22e/tarantool-1.6.8-0.284.fc24.src.rpm Buildbot: http://koji.fedoraproject.org/koji/taskinfo?taskID=12380233 Changes: - Change naming scheme according to #1293100 comments - Remove SCL support - Remove devtoolkit support - Fix tarantool-common /usr/lib64 conflicts - Use system libyaml I need a review for this version of spec. Thanks! -- 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