Re: [PATCH v4 2/2] version-gen: fix versions

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Oct 14, 2013, 05:29 UTC
Message-ID: <CAMP44s3PfRVV5V4=iddR2AOdnqhOt5oi8Wx9nS=2x=z_kN2wjw@mail.gmail.com>
In-Reply-To: <20131014050104.GA25344@google.com>

On Mon, Oct 14, 2013 at 12:01 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 15 quoted lines

> Hi,
>
> David Aguilar wrote:
>> Felipe Contreras <felipe.contreras@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

Show 10 quoted lines

> -- >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.

Show 10 quoted lines

>  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?

Show 7 quoted lines

> 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?

Show 7 quoted lines

> [...]
>> 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