On Mon, Oct 14, 2013 at 12:01 AM, Jonathan Nieder <jrnie...@gmail.com> wrote: > Hi, > > 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:
It's not Red Hat's convention, it's RPM, and dpkg, so basically every package manager that most distributions out there use. And I already sent a patch for that which was ignored: http://article.gmane.org/gmane.comp.version-control.git/234794 > -- >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)) That wouldn't work; VERSION doesn't have '-rc', it has '.rc'. and what's the point of creating a new variable? It's a was of space. > 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, Do you have any evidence that such programs exist? Specifically, programs that work with 1.8.4.rc1, but not 1.8.4-rc1 or 1.8.4~rc1. I find that very very very unlikely. Anyway, in the very very very unlikely scenario that somebody's script does break they can report that, and we can revert. What's the problem? > but > the packaging system would get the benefit of the proposed versioning > style change. > >>> The same happens in dpkg. > > Have you tested this? % dpkg --compare-versions 1.8.4 gt 1.8.4~rc1 && echo yes || echo no yes % dpkg --compare-versions 1.8.4 gt 1.8.4-rc1 && echo yes || echo no no > I thought the Debian packaging did not use the > GIT-VERSION-GEN generated version in this way. It doesn't matter. The name of the package would be git-1.8.4~rc1, and 'git --version' would return 1.8.4.rc1, that's inconsistent. Why be inconsistent when we can be consistent? > [...] >> 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. Because a) they don't package release candidates, and b) they use a different version (s/\./~/). -- Felipe Contreras -- 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
