David Aguilar wrote:
> Felipe Contreras <felipe.contre...@gmail.com> wrote:
>> Virtually all packaging guidelines would prefer 1.8.4~rc1, over
>> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
>> In particular, the only packaging we provide, git.spec, generates a
>> wrong version, because git-1.8.4 < git-1.8.4.rc1, changing to ~rc1 fixes
>> the problem as it's considered newer.
A more conservative fix would be to tweak the .spec generation in the
Makefile to follow whatever the appropriate Red Hat convention is.
For example, something like this:
-- >8 --
diff --git i/Makefile w/Makefile
index 0f931a2..73bd89d 100644
@@ -2385,8 +2385,9 @@ quick-install-html:
### Maintainer's dist rules
+GIT_VERSION_RPM = $(subst -rc,~rc,$(GIT_VERSION))
git.spec: git.spec.in GIT-VERSION-FILE
- sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+
+ sed -e 's/@@VERSION@@/$(GIT_VERSION_RPM)/g' < $< > $@+
mv $@+ $@
GIT_TARNAME = git-$(GIT_VERSION)
-- 8< --
That way, programs that parse the git version by splitting at '.'
(there are more than a few, unfortunately) would continue to work, but
the packaging system would get the benefit of the proposed versioning
>> The same happens in dpkg.
Have you tested this? I thought the Debian packaging did not use the
GIT-VERSION-GEN generated version in this way.
> This seems related:
If I understand correctly, that page has an exhaustive list of affected
packages in the Debian archive and doesn't include git.
Thanks and hope that helps,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html