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
--- i/Makefile
+++ w/Makefile
@@ -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 $@+ $@
-- 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
style change.

>> 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:
> http://lintian.debian.org/tags/rc-version-greater-than-expected-version.html

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

Reply via email to