Describe the problem you're observing
Disclaimer: I've not run into this issue yet, but it seems like an issue should would be good to document and provide a place to discuss acceptable solutions.
Currently, rpm package builds from a git repo will have a version of 2.4.99-<num>_g<commit> (and will be 2.4.99-<num>.g<commit> when #18938 is merged, but the change is inconsequential for this issue), where <num> is the number of commit past the last major release (eg. 2.X). Having the main release number be the number of commits is fine so long as one only ever builds from a clean master because master (should) never rewrite history and so the number of commit is monotonically increasing. That is not necessarily true for builds that add commits to master and can cause problems.
Concrete example: Suppose that a user wants to use ZFS from master + various pull requests. Sometimes chosen pull requests are determined to be undesirable and are removed from the list of pull requests tracked. Sometimes pull requests are updated and the number of commit decreases. When the number of commits decreases from the last such installed build, then the newly built packages have a version that compares to less than what is installed, requiring a downgrade to install the packages. Ideally, versions should be monotonically increasing.
Also, if the user, separately, builds a package from a dirty repo at the same commit as the last installed build, the version numbers are exactly the same. This is mostly expected, but there's no good option for the user to change this without patching config/zsf-meta.m4.
The user might think that they could increment manually the release number in META, but for git builds the release value in META is ignored. My suggested solution is to honor the release value in META by having the release string be <meta release>.<num>.g<commit>. This way the user can manually increase the version if needed (eg. in the example above where otherwise a new build would have a version lower than an existing one).
This would all work great, afaict, if it were the starting point. The problem then becomes that if a user already has an install built from git. In that case, the <num> could, and currently is, in the hundreds. Using the existing release value of 1 would mean that a new version would be 1.<num>.g<commit>. This of course will be less than the old release, requiring an undesirable downgrade.
I don't see clear-cut desirable solutions, and here's a few of them:
- Accept a one time hit for git build users - unfortunately, I believe it likely that this will affect more users than the number affected by this issue
- Introduce
Epoch in the version - prefixes version with epoch, which may look strange to some users.
- Increment
Release in Meta by 1000 in config/zfs-meta.m4 - not great because the user set a value in META, but the output is confusingly 1000 + release.
Any other solutions?
Describe the problem you're observing
Disclaimer: I've not run into this issue yet, but it seems like an issue should would be good to document and provide a place to discuss acceptable solutions.
Currently, rpm package builds from a git repo will have a version of
2.4.99-<num>_g<commit>(and will be2.4.99-<num>.g<commit>when #18938 is merged, but the change is inconsequential for this issue), where<num>is the number of commit past the last major release (eg. 2.X). Having the main release number be the number of commits is fine so long as one only ever builds from a clean master because master (should) never rewrite history and so the number of commit is monotonically increasing. That is not necessarily true for builds that add commits to master and can cause problems.Concrete example: Suppose that a user wants to use ZFS from master + various pull requests. Sometimes chosen pull requests are determined to be undesirable and are removed from the list of pull requests tracked. Sometimes pull requests are updated and the number of commit decreases. When the number of commits decreases from the last such installed build, then the newly built packages have a version that compares to less than what is installed, requiring a downgrade to install the packages. Ideally, versions should be monotonically increasing.
Also, if the user, separately, builds a package from a dirty repo at the same commit as the last installed build, the version numbers are exactly the same. This is mostly expected, but there's no good option for the user to change this without patching
config/zsf-meta.m4.The user might think that they could increment manually the release number in
META, but for git builds the release value inMETAis ignored. My suggested solution is to honor the release value inMETAby having the release string be<meta release>.<num>.g<commit>. This way the user can manually increase the version if needed (eg. in the example above where otherwise a new build would have a version lower than an existing one).This would all work great, afaict, if it were the starting point. The problem then becomes that if a user already has an install built from git. In that case, the
<num>could, and currently is, in the hundreds. Using the existing release value of1would mean that a new version would be1.<num>.g<commit>. This of course will be less than the old release, requiring an undesirable downgrade.I don't see clear-cut desirable solutions, and here's a few of them:
Epochin the version - prefixes version with epoch, which may look strange to some users.ReleaseinMetaby1000inconfig/zfs-meta.m4- not great because the user set a value inMETA, but the output is confusingly1000 + release.Any other solutions?