Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 09:59:43AM +0200, Adam Borowski wrote:
> 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.
So what does this have to do with producing a suffix to put on an upstream
version for a Debian package?
> > 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.
Can't you tell git to retrieve a tag (and all commits therefrom) from a
remote repository? If not, what *is* the point of a git tag?
> > 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.
git --describe is, as far as I can tell, useless for the purpose stated at
the beginning of the thread.
- Matt
Reply to: