Hi, David Aguilar wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 $@+ $@ 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 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, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html