Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote:
> On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote:
> > 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.
You can't compare unversioned branches to other branches anyway. If you
move from one branch to another, you need to label that manually.
Git's scheme provides enough versioning to handle anything that can be done
in automated way. Indeed, packaging multiple branches stemming from the
same tag may give versions that are not sufficiently sortable, but there's no
way to tell which branch is the "lesser" and which is the "greater" one
without human intervention.
The hash prefix is there just to catch cases where you have some unofficial
or cherry-picked patches, or the branch is not exactly what the reader
expects.
> 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.
This would be bad, as your tags won't say anything about the version you
package. Without a mapping between your tags and particular commits,
there's no way to tell what upstream source you refer to.
> If it is ambiguous, you can always put that sort of information in the Debian
> changelog, or perhaps README.source.
git --describe doesn't have that pesky requirement.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: