Mailinglist Archive: opensuse-packaging (155 mails)

< Previous Next >
Re: [opensuse-packaging] Re: Proper version scheme for packages from git, hg, svn, ...
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Sat, 11 Jan 2014 11:56:18 +0000
  • Message-id: <20140111115618.GC13009@pacific.linksys.moosehall>
Jan Engelhardt (jengelh@xxxxxxx) wrote:
On Saturday 2014-01-11 00:40, Adam Spiers wrote:

Please can you explain exactly how you would programmatically obtain
the "tag-offset"

It's described in text form in the wiki article.

#!/usr/bin/perl
use IPC::Open3;
use strict;

[Orthogonal to this discussion, but if you must use Perl, please:
never, EVER omit "use warnings;"]

sub grab {
local(*CIN, *COUT, *CERR);
my $pid = open3(\*CIN, \*COUT, \*CERR, @_);
chomp(my $line = <COUT>);
close(CIN);
close(COUT);
close(CERR);
waitpid($pid, 0);
return ($line, $? >> 8); # need something better than "$?"?
}

sub result {
print "Version: $_[0]\n";
exit(0);
}
my $commit = shift(@ARGV) || "HEAD";
my $pattern = shift(@ARGV) || "*";
my @args = ("git", "describe", "--match=$pattern",
"--abbrev=0", $commit);
my($base, $err) = &grab(@args);
if ($err != 0) {
chomp(my $len = `git rev-list "$commit" | wc -l`);
&result("0~git$len");
}
splice(@args, 3, 1); # remove --abbrev=0
my($offset) = &grab(@args);
&result($base) if ($base eq $offset);
&result("$base~git$offset") if ($offset =~ s{^\Q$base\E-(\d+)-g\w+$}{$1});
print STDERR "This should not happen.\n";
exit(1);

No need to grab the base separately, just use --long:

sub offset {
my $commit = shift || "HEAD";
my $pattern = @_ ? shift : "*";

my ($tag, $offset, $hash) =
`git describe --long --tags --match=$pattern "$commit" 2>&1`
=~ /^(.+)-(\d+)-g([0-9a-f]+)$/;
return $offset unless $?;

$offset = `git rev-list "$commit" | wc -l`;
$? ? die "failed to get offset" : $offset;
}

The version ought to be monotonically increasing somehow. The
timestamp does that, sure, but so does the tag-offset (for a given
branch that is being continuously packaged)

and explain why it is reliably monotonically increasing?

If you stay on a given branch, if you make a commit, you add +1 to
the distance. If you make a merge commit, you add some +n (n>0) to
the reported distance.

Yes, I already understand the basic concept :-) I was specifically
asking for an explanation which deals with problems such as this:

For example, if a non-release tag is introduced into the
repository, how would you ensure that the tag-offset doesn't suddenly
drop back to zero?

git describe --match=

One would at least hope you name your release tags reasonably unique
that they are programmatically distinguishable from nonrel tags (that
would also be worthwhile from a human perspective).

So to be clear, you are suggesting a generally applicable technical
solution based on hope?

And then there's still the case where there are no tags, and I don't
agree with the point of view that every repository should have tags.

And the wiki page (and the perl above) has a solution for that as
well, which would tell me you did not visit the wiki page again ever
since last September's discussion.

Your inference is mistaken. Regardless, that is not a valid solution,
because it breaks instantly when the first tag is introduced to the
repository.

Don't get me wrong - *aesthetically* I prefer the idea of being able
to use tag offsets: a single monotonic integer metric is a bit more
elegant than a timestamp. But unfortunately I don't think they offer
a workable solution.

The discussion about whether %version should also be suffixed with a hash
is orthogonal to the "timestamp vs. tag offset" debate, and I have
already explained elsewhere the value of including the hash.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups