mirror of
https://github.com/versity/scoutfs.git
synced 2026-02-09 12:10:09 +00:00
22f1ded17b
This adds in the makefile targets and spec file template we need to build RPMs. Most of the heavy lifting is taken care of by our docker container and the rpmbuild.sh script distributed in it. The git versioning comes from 'git describe --long', which gives us the tag, the number of commits and the abbreviated commit name. This allows us to use the number of commits as the RPM release version, letting yum understand how to process 'yum update' ordering. yum update shows us the proper processing, along with how our versioning lines up in the RPMs: ---> Package kmod-scoutfs.x86_64 0:0-0.3.gb83d29d.el7 will be updated ---> Package kmod-scoutfs.x86_64 0:0-0.4.g2e5324e.el7 will be an update The rpm file name is: kmod-scoutfs-0-0.4.g2e5324e.el7.x86_64.rpm When we build release RPMS, we'll toggle _release, giving us a rpm name and version like kmod-scoutfs-0-1.4.g2e5324e.el7.x86_64.rpm. The toggle of 0/1 is enough to tell yum that all of the non-release RPMs with the same version are older than the released RPMs. This allows for the release to yum update cleanly over development versions. The git hash helps map RPM names to the git version and the contents of the .note-git_describe, for this RPM it was: heads/nic/rpms-0-g2e5324. The RPM doesn't contain the branch name, but we can add that and other info later if needed. We are not naming the module for a kernel version, that does not seem to be standard practice upstream. Instead, we'll make use of our Artifactory repos and upload the RPMs to the correct places (7.3 vs 7.4 directories, etc).