Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote:
> On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote:
> > Matthew Palmer <mpalmer@debian.org> wrote:
> > > > sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d
> > > Yeah, that isn't going to work -- what if the next SHA you want to
> > > package is 12345[blah]... it'll look like a lesser version to dpkg.
> > I had a similar problem when I moved roxterm to git [1]. I only use
> > git-derived versions for testing between releases but it's still useful.
> > Here's a bit of script that can help:
> >
> > Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'`
> > Rev=`date -d "$Date" -u +'%Y%m%d%H%M%S'`
>
> Why won't you just use `git --describe`?
> It produces nice version numbers of the format
> <last tag>-<number of commits after it>-<start of hash>
> (or just <last tag> when you're packaging a release)
>
> The "start of hash" is a way to disambiguate in the case of multiple
> branches based on the same release that happen to have the same number
> of commits past that it; it will be the minimal repo-wide unambiguous
> hash not shorter than (by default) 7 characters.
You cannot use hashes in your version strings, because you can't assume that
the "later" version is going to sort after the "earlier" version. If
<tag>-<commitcount> isn't sufficiently unique, you're stuffed.
Using a tag, however, is a possibility I hadn't considered. If you merge
from upstream at relevant points and then tag in your repo, you could use
0.x.y~<tagname> as the upstream version. Again, README.source would need to
document this convention, but you can control the content of the tag to make
it monotonically increasing.
> Unlike homebrewed versioning schemes, this one can be understood by git
> without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b
> or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6.
For Debian packaging, this is irrelevant.
> I recommend against using dates to mark revisions, since there probably
> will be multiple commits in a single day, so there is no way to tell
> which exactly version you did package.
If it is ambiguous, you can always put that sort of information in the Debian
changelog, or perhaps README.source.
- Matt
Reply to: