Re: [PATCH] rpmbuild doesn't like '-' in version strings

From: John Ellson <ellson@research.att.com>
Date: Jan 14, 2006, 15:39 UTC
Message-ID: <43C91B25.9030707@research.att.com>
In-Reply-To: <7voe2prniw.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 25 quoted lines

> John Ellson <ellson@research.att.com> writes:
> 
>> Suggested fix:  Use '_' instead of '-'
> 
> I wonder if the right fix is to change the git-describe output
> before the current output becomes too widespread.  After all,
> somebody might be tempted to use 1.0.6-g58e3 as a tagname ;-).
> For example, if we say "1.0.6:58e3" there is no ambiguity, but
> probably binary packagers would not like colon either X-<.
> 
> More seriously, I do not think git-describe based versioning
> scheme meshes well with binary packagers.  There is no guaranee
> 1.0.6-g58e3 comes before 1.0.6-g4e7a2 (it does not).  To really
> fix this problem, I think the rpm target of the main Makefile
> needs to be modified to include something monotonicly increasing
> (e.g. number of seconds since the base commit encoded in base26,
> or something silly like that) between the base version and the
> abbreviated object name, but the development being distributed,
> my today's version on top of 1.0.6 may be way behind your
> yesterday's version, so some centralized coordination (read:
> manual version assignment by the maintainer, or automated
> assignment but only reserved for the maintainer and unavailable
> to mere mortals) might be needed to truly solve this.  In that
> sense, maybe leaving the interim version unbuildable for binary
> packaging might be considered a feature.

What happened to this? I don't particularly like my fix either, but some kind of fix is needed for the "make rpm" target to work. Its still broken because of the '-' in the version string.

The need in rpm versioning is to be able to distinguish and monotonically order, locally built rpms. There is no particular need to disambiguate against somebody else's rpms since if you are merging someone else's changes you would be doing it in git and not by intermixing rpms.

I think that distinguishing between local branches is not likely to be a prolem. 
  Most developers are likely to use only one for rpm construction, or if there 
is a second experimental branch, then it is likely to contain more-recent 
changes anyway.

So a count of minutes since last tag is probably sufficient.

This could have a hash appended if it is essential to make the rpm version unique without losing the ordering of the timestamp.

Something like:

	1.1.2_123456_g9e9b

John