Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. [...] Here's a small list of flavors that I've come across or used myself.[...] TL;DR: My recommendation would be to (at least loosely) follow pattern 5) versioning.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long

True, that is an *aesthetic* disadvantage. But does it have any significant negative impact in practical situations?

hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master.

I disagree: 1. The aim of this thread is (presumably) to establish a common standard which can be used consistently across many projects. *Plenty* of projects do *not* have linear history, therefore a standard should not make assumptions about whether it is linear or not. 2. hashes are needed even when history is linear, because then you know exactly which source revision the package came from, and in a support situation this is crucial information. In general there is no reliable way of determining this from a timestamp, because the timestamp could refer to when the git commit was made, or when tar_scm was run, or when set_version was run, or even some arbitrary value which the maintainer manually put in the .spec file. However, like I just mentioned in my other mail to this thread, the hash could potentially be embedded in %description and omitted from %version. But I'm against this, because it makes the output of "rpm -qa" a lot less useful. Even the kernel developers include the hash in both %description and %version.

TL;DR: http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v...

Clearly those guidelines are flawed, because as Sascha already pointed out, they result in non-chronological ordering which breaks upgrades. I think the main point of this thread is to try to fix that. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting Sascha Peilicke <speilicke@suse.com>:

Ideally, that would be the result, yes. I'd like to have some (documented) best practices which are good to follow in all cases without much debate. Secondly, I'm a Factory reviewer and I can't recall how often I re-read the RPM version comparison algorithm because someone went creative again :-) Less deviation means faster and less error-prone reviews and thus happier packagers.

Don't read code.. use "zypper vcmp". After all, zypper is our only source to truth when we talk about updates (ok, actually libzypp). Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Matwey V. Kornilov (matwey.kornilov@gmail.com) wrote:

10.09.2013 15:33, Jan Engelhardt пишет:

...

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. [...] Here's a small list of flavors that I've come across or used myself.[...] TL;DR: My recommendation would be to (at least loosely) follow pattern 5) versioning.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master.

TL;DR: http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v...

Should I assume that guidelines at the link have been fixed

They haven't.

according the decision token after this terrible long discussion?

Well, I spammed the thread with my opinions, and IMHO I *believe* that I successfully countered any objections to the scheme which my team favours ... but I'm not sure whether the fact that there were no more *publically stated* objections counts as a consensus ;-) I'm not even sure what the process would be for formally finalising such a decision. Well, I suppose it's only a guidelines document not a strict policy, so maybe we should just update the wiki page with the points covered in the thread. Any volunteers? /me looks at the OP (Sascha ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Friday 2014-01-10 21:06, Adam Spiers wrote:

...

...

10.09.2013 15:33, Jan Engelhardt пишет:

...

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations

Should I assume that guidelines at the link have been fixed

They haven't.

They were not broken, so they did not need fixing.

Broken is probably too strong a word, but they could be improved ;-p

...

Well, I spammed the thread with my opinions, and IMHO I *believe* that I successfully countered any objections to the scheme which my team favours ... but I'm not sure whether the fact that there were no more *publically stated* objections counts as a consensus

Didn't you read the fineprint - "period for appeal is 8 weeks, starting with the reception of [last mail in discussion]"? :)

;-) Well, a few of my points went unanswered, as I'll note below.

Let's recap for "1363873583.8dfab15" (TS.HASH):

* 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) while at the same time, the latter is much shorter.

Please can you explain exactly how you would programmatically obtain the "tag-offset", and explain why it is reliably monotonically increasing? 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? I already pointed out this flaw in September: http://lists.opensuse.org/opensuse-packaging/2013-09/msg00099.html but still noone has explained how it could be circumvented. 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. It's up to each maintainer whether they wish to issue releases or operate according to a continuous development model. Package versioning guidelines should not be opinionated about development models.

* If people ship different branches, they do so in different BSprjs (cf. network:samba:), or with different package names (cf. squid/squid3/squid-beta) rather than (a) implanting that into %version or even (b) implying it through the hash.

Nope, branches very often correspond to releases, therefore the branch is often indicated by *both* the BS project *and* the first part of %version. For example, Cloud:OpenStack:Grizzly has a bunch of openstack-* packages whose %versions begin with "2013.1", whereas Cloud:OpenStack:Havana %versions begin with "2013.2". That's obviously useful, because you can instantly tell from rpm -qa which version of OpenStack is installed.

* Adam Spiers says: "hashes are needed even when history is linear, because then you know exactly which source revision the package came from". This is a Microsoft Balloon[1] argument;

Error: aborting due to dangling footnote reference at line 16 ;-)

it _might_ be usable in _some obscure_ way

Sorry, this is plain wrong. There is no debate whatsoever about whether it's usable, because I use it on a regular basis when debugging errors reported by users. And there's nothing remotely obscure about the way I use it; I simply git checkout the hash, or eyeball the corresponding revision in gitk or similar. It seems that you are in favour of embedding the hash in %description instead. How is that any more usable or less obscure?

you can have your hash. But that does not change the fact that it is still very much a niche-indicator.

On what evidence are you basing this assertion, and what's your point?

The kernel people (samba too?) recognized that and placed it into %description instead - with complete branch info by the way.

I have no objections with including extra meta-data in %description; in fact I would encourage it. But that still does not solve the problem regarding bug reports: http://lists.opensuse.org/opensuse-packaging/2013-10/msg00008.html

In summary: objections have been objectioned, leaving the arguments for TS.HASH with what it seems to be of no to little weight.

Sorry, but that's a wholly inaccurate summary. As highlighted above, I have two strong objections to the git-oriented aspects of the SCM snapshots section of the existing guidelines[1], neither of which have had solutions provided yet: 1. Tag offsets are not reliably monotonically increasing 2. Bug reports often provide little more than an rpm version number and an error message (or stack trace, if you're lucky). So if the %version doesn't point to an exact source revision then life gets harder. There's the other point about repositories with no tags, but I suspect we'll have to agree to disagree on that.

You can still use TS.HASH, but you won't find a majority (in terms of mass) to back it.

Of course you're entitled to your personal opinions about likely adoption. But that's putting the cart before the horse, because a guidelines document which just describes what the majority believe is about as useful as a web page which advises people to "use Windows or MacOS X". Anyway, I'm not interested in finding a majority (let's face it, not many people care about this stuff to this level of detail anyway); I'm interested in finding the optimal solution. [1] https://en.opensuse.org/openSUSE:Package_naming_guidelines#SCM_snapshots -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) 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@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Saturday 2014-01-11 12:56, Adam Spiers wrote:

...

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

Grabbing the base separately is necessary to catch the (braindead) case that you have a tag called "v3.4-5-g1234567". If you just run git describe, you therefore could not determine whether your current HEAD is (v3.4-5-g1234567)-0-g9876543 or (v3.4)-5-g1234567.

Like I said, --long solves that case, because it *always* outputs the long format, so there is no ambiguity.

...

...

...

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?

I am suggesting that people not turn off their brains.

You don't just make a non-release tag and give it a name like a release tag.

OK, so let's assume I have a bunch of tags like: v1.0.1 v1.0.2 etc. We are looking for a programmatic solution which can be automated by tools such as tar_scm. You are presumably suggesting to use something like git describe --match='v[0-9]*.[0-9]' right? But there is no pattern which for release tags, and non-release tags, therefore you are introducing the requirement for a custom glob per project. And this glob is necessarily brittle, because very often the person maintaining the upstream repository containing the tags is different to the person maintaining the downstream package, and will have zero awareness that someone else is hoping they will ensure that a) all their release tags match this glob, and b) none of their non-release tags match this glob. Furthermore, this would mean that the tar_scm source service would require an extra parameter (which only applies in the git case). It also would require a patch to tar_scm to add support for your tag offset mechanism. I believe in freedom of choice, so I would gladly accept a pull request from you which supports that scheme, in order that people like yourself can use it. However, in contrast, the timestamp approach already works out of the box with tar_scm, and has none of the brittleness described above. So IMHO it's a better scheme to recommend in the guidelines wiki page.

...

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

And why would that be?

Because the tag offset will reset to zero, violating the requirement that it increases strictly monotonically. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Saturday 2014-01-11 14:53, Adam Spiers wrote:

...

OK, so let's assume I have a bunch of tags like: v1.0.1 v1.0.2 etc. We are looking for a programmatic solution which can be automated by tools such as tar_scm. You are presumably suggesting to use something like git describe --match='v[0-9]*.[0-9]'

right?

With the match pattern be an argument to whatever script calls that, because that is invariably user-specific, which is also why the match pattern was an argument in the perl script I had posted.

Right, so I understood you correctly.

Hence, all I really asked of the user is to name his tags such and such that he himself can give a reasonable short algorithm to distinguish them.

You're asking that of the *maintainer*, not the packager.

...

And this glob is necessarily brittle, because very often the person maintaining the upstream repository containing the tags is different to the person maintaining the downstream package,

An upstream can always screw up downstream -- heck, they do all the time with something as banal as release tarballs' filenames, which affects our URIs in Source: lines in .spec files, and /debian/watch.

True, but that's out of scope for this discussion about versioning of snapshots directly from an SCM repository.

So, 'lo and behold, git tags are no different.

... which is why I have repeatedly argued that it is not a good idea to rely on them. OTOH, a timestamp is a timestamp, and *can* be relied on, short of the branch being changed or the history rewritten, in which case all bets are off anyway. We don't need to get too concerned about stuff we can't defend against, but we *can* defend against the unreliability of tags.

...

...

...

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

And why would that be?

Because the tag offset will reset to zero, violating the requirement that it increases strictly monotonically.

The offset may move to zero, but in the same go, the tag is increased by "one". Making %version go from 2013.1-1500-gxxxx (2013.1~git1500) to 2013.2-1-gxxxx (2013.2~git1) is perfectly fine.

The tag name is not automatically transplanted into %version. You yourself already described doing that as "almost stupid": http://lists.opensuse.org/opensuse-packaging/2013-09/msg00086.html Therefore this requires the packager to be constantly on the lookout for a tag offset suddenly decreasing, which again is brittle for multiple reasons: - The packager is very often not the upstream maintainer (in fact I'd guess this is true in the majority of cases). - It's not enough to look for a tag offset which drops to zero, because the source service might not run until after several commits since the creation of the new (or first) tag. So it's possible that the offset could drop from (say) 5 to 4, which would be very easy to miss. Worse, if the source service is configured to run automatically server-side, breakage is almost guaranteed after the new tag has been created upstream. It's not at all clear to me why you are so strongly against using timestamping instead, which suffers from none of these problems. Yes, I agree that aesthetically it's maybe not quite as nice, but that's a triviality when compared to the goal of building a robust solution. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Saturday 2014-01-11 17:32, Adam Spiers wrote:

...

...

are available in the git repository at: git://git.inai.de/obs-service-tar_scm master for you to fetch changes up to 3c38cd32941dfc51ac1245c9de91fd63e29969fe: tar_scm: support retrieving the git tag offset (2014-01-11 16:26:46 +0100)

However, please can you submit this to a fork on github,

I don't use github, sorry.

This is not a personal choice, it's how the project operates. github and Travis are an integral part of the development workflow for tar_scm (and many other openSUSE projects). I can't imagine why you wouldn't use github, but if you don't then you'll find it a lot harder to contribute in general. Personally I will not merge a branch for which I cannot conduct a code review in public, and I would encourage all the other maintainers to adopt the same stance, because transparent peer review is a Very Good Thing. Suitable vehicles for public review include github and gerrit (where available), and git format-patch for an email-based workflow. However in the tar_scm case, it has to be github because we already have it tied to Travis for automated test runs.

...

- It's missing a corresponding addition to the test suite. That's a show-stopper ;-)

Surely you can address that, because I don't write python a lot either.

I could but I don't have time. Besides, the person who writes the code should also write the tests. It's called Test-Driven Development.

...

- I don't think "@REVISION@" is the best choice of placeholder name; it's too misleading. Something like @TAG_OFFSET@ would be better.

I would have picked %r because that already gets you a number with svn/hg, but %r is prone to clash with git itself in the future, so *throws up hands in the air*.

Like I said, @TAG_OFFSET@ or similar is a big improvement.

...

- In general I agree that shell variables could be quoted during expansion. But quoting variables like $? and $# is overkill, since they will never be the empty string. Furthermore, in bash the quotes are redundant when you are using the double [[ ]] parentheses:

Alas, the original programmer did not think of using [[ ]] everywhere. So, safest option: [[ and ".

No, the logical conclusion is to use either a) [ ] and "", or b) [[ ]] and no "". Using "" with [[ ]] is redundant and unnecessarily noisy. I agree that consistent use of either [ ] or [[ ]] rather than a mixture of both would be nice, but that's totally orthogonal to the discussion of quoting.

...

...

Specifying the basetag also has the advantage that @REVISION@ does not go back to 0 without the bspkg maintainer noticing, which is also a property that %ct seemed to hold in case a new git tag (e.g. v0.3.3) was created while _service was left at versionformat=0.3.2.something.

Ah OK, you've changed your design! Yes, this is *much* better than some fluffy git describe --match=GLOB logic; finally it addresses the main flaw in your scheme.

I would not call it a flaw.

It was a flaw for the reasons which I have already stated several times - in short, it was too brittle due to the possibility of new tags being added to the upstream project. However, your new idea of fixing the tag string completely addresses that, which I'm very happy about :)

...

There's still a small risk that upstream repositions the tag in question,

That is (even more) haphazard than repositioning a branch head, because tags - unlike branch heads - don't get force-updated when a client runs git-fetch.

Agreed! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Monday 2014-01-13 15:38, Adam Spiers wrote:

...

...

However, please can you submit this to a fork on github,

I don't use github, sorry.

This is not a personal choice, it's how the project operates. github and Travis are an integral part of the development workflow for tar_scm (and many other openSUSE projects). I can't imagine why you wouldn't use github,

Because I don't have to. Git is reasonably distributed that I can host the repository itself. By forcing people to use a specific service, you throw the git effect overboard, and add an entry barrier instead. Just like non-git is said to be.

to contribute in general. Personally I will not merge a branch for which I cannot conduct a code review in public,

I shall gladly post the patchez as mail. (I think I indeed might have only sent the pull cover mail.)

Like I said, @TAG_OFFSET@ or similar is a big improvement.

Then again, if there is no tag, we compute the distance to the history root instead. So @TAG_OFFSET@ isn't totally accurate either. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 14.01.2014 15:51, Adam Spiers wrote:

...

Then again, if there is no tag, we compute the distance to the history root instead. So @TAG_OFFSET@ isn't totally accurate either.

Good point; any better suggestions are very welcome.

I would call it the distance or the metrics. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

14.01.2014 17:21, Adam Spiers пишет:

Hmm... I think "distance" implies a continuous amount (i.e. float) rather than a discrete number (integer),

The distance implies that Distance(A,B) == Distance(B,A), Distance(A,A) = 0, Distance(A,C) <= Distance(A,B) + Distance(B,C). No matter continuous or discrete. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 01/23/2014 04:49 AM, Adam Spiers wrote:

Matwey V. Kornilov (matwey.kornilov@gmail.com) wrote:

...

14.01.2014 17:21, Adam Spiers пишет: When I said "a continuous amount (i.e. float) rather than a discrete number (integer)", I meant "as well as", because integers are of course a subset of irrational numbers. So we agree that the term "distance" implies the possibility of a non-integer amount, which again is something we need to avoid in this context.

Adding nothing to the actual discourse other than a nit-picky correction: I suppose you mean to say either "rational" or "real" numbers here as integers are not a subset of irrational numbers. ;) --Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi Adam, Am 14.01.2014 12:51, schrieb Adam Spiers:

...

Just like non-git is said to be.

Apples and oranges. Structured development processes are *nothing* like being forced to use an antiquated SCM.

I don't think Jan is opposed to using git (he offered to push his clone somewhere IIRC), he is opposed to using github. Which are two different subjects. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2014-01-14 14:18, Adam Spiers wrote:

...

I don't think Jan is opposed to using git (he offered to push his clone somewhere IIRC)

No, he actually did push it - not just offer.

.oO(But putting it up and talking about it on a public mailing list, I at least fulfill "offering" in a legal sense.) ~random thought~

...

he is opposed to using github. Which are two different subjects.

Yes, I was fully aware of that. But he was claiming a similarity between requesting submissions via github and using a non-git solution

The intent was to say: Requestion a github submission would seem to require registering at Github, which _poses_ an entry barrier. A non-git solution would also pose an entry barrier. In both cases significant enough to just walk away. http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-... says "Submit patches in the way upstream wants to receive them" Yes, but tread lightly. A good maintainer should be prepared to accept nonperfect submissions massage the code to his needs, doctrines or development environment. Rejecting a patch that fails to apply with TortoiseSVN even though it is totally compliant to the unified diff specification is something not within my maintainer ideals. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2014-01-14 16:36, Adam Spiers wrote:

...

In both cases significant enough to just walk away.

I really cannot understand this. I have already given two very clear benefits of adhering to a github-oriented workflow, namely transparent peer code review, and automated testing via Travis. Despite this you have stated, without any explanation why, that you are not prepared to spend the 60 seconds required to create a github account

Because it's another account that wants to be managed. It's more than 60 seconds in the long run. I could make it a trash account, but I'd forget those even faster and would have to recreate one everytime. It's all the reason (I would envision) why the kernel is still developed on a mailing list and nothing else - even their bugzilla is optional.

The success of this feedback loop depends on the willingness of both parties to iterate until there is consensus. It will *not* succeed if the contributor simply throws a bunch of patches over the wall and then walks off expecting the maintainer to do the rest of the work.

Well for one, you _called_ for patches. Don't complain if you get some ;)

...

Rejecting a patch that fails to apply with TortoiseSVN even though it is totally compliant to the unified diff specification is something not within my maintainer ideals.

Please can you explain how that is relevant here?

It's one of my experiences where "Submit it in a format the maintainer wants" was driven too far. If the thing is on review on github, good. If not, screw it. I don't care. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Sat, 11 Jan 2014 08:47:18 +0100 (CET) Jan Engelhardt <jengelh@inai.de> пишет:

my @args = ("git", "describe", "--match=$pattern", "--abbrev=0", $commit);

Should not it use --first-parent? Otherwise there is risk to pick up wrong tag from merged branch.

chomp(my $len = `git rev-list "$commit" | wc -l`);

Why not "git rev-list --count $commit"? (Same comment about --first-parent) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 2014-01-10 20:44, Matwey V. Kornilov wrote:

10.09.2013 15:33, Jan Engelhardt пишет:

...

On Tuesday 2013-09-10 13:22, Sascha Peilicke wrote:

...

I'd like to gather some input on versioning schemes used for packaging SCM snapshots.

Pattern 5 "X+git.1363873583.8dfab15" is terribly long, and hashes are useless in many situations, either because history is practically linear (like systemd's git) or because you are only ever following master.

http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v...

Should I assume that guidelines at the link have been fixed according the decision token after this terrible long discussion?

The last significant changes were made the same day I pointed at the URL. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 09/10/2013 01:40 PM, Adam Spiers wrote:

Sascha Peilicke (speilicke@suse.com) wrote:

...

Hi guys,

I'd like to gather some input on versioning schemes used for packaging SCM snapshots.

[snipped]

...

1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

You can of course argue about dots vs, any other separating paragraph. Also, instead of "+git", you may prefer sth. different (along as it won't break RPM's version comparison mechanism).

TL;DR =====

My recommendation would be to (at least loosely) follow pattern 5) versioning if you ever have to package from SCMs. While devel projects are rather free to do whatever they prefer, I'd say it's appropriate for Factory submissions.

+1 for number 5), although I'm somewhat biased, because IIRC it was me that originally proposed that scheme for OpenStack packages ;-) It seems to have worked well for us over the last 18 months.

;-)

At the time I think there was also some discussion of also embedding git metadata within the rpm %description. It's interesting to see what the kernel guys are currently doing, e.g.:

$ rpm -qi kernel-desktop-3.7.10-45.1.gff50a00 | tail -n4 Source Timestamp: 2013-07-26 15:39:00 +0200 GIT Revision: ff50a00e96dbde96e962b6cd9f871bb710efa9c3 GIT Branch: openSUSE-12.3 Distribution: Kernel:openSUSE-12.3

For the Kernel it's definitely useful since users that check this package probably know what they're doing. For leaf-packages where knowledge of git (or $SCM) can't be taken for granted, I'm not sure if this only adds confusion. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

Quoting Sascha Peilicke <speilicke@suse.com>:

On 09/10/2013 01:50 PM, Dominique Leuenberger a.k.a. Dimstar wrote:

...

They have their merits and disadvantages of course. I'd not go as far as making the format a requirement for Factory checkins.

Sure, as mentioned somewhere I for now look at some generic recommendations / best practices.

...

There are short-living packages and longer-living ones; a package 'always' depending on git snapshots probably wants to express this in the version number; a package doing this 'temporarily' to overcome an obstacle might be fine with any other, shorter, for and only specify the exact commit / branch in the .changes file.

But even then, correctness won't hurt. Even if the git snapshot is temporarily, people want to know which commit was picked. Format 1) doesn't seem to provide this info.

We both know you were triggered by my PA submission for this; so let's just use it as an example. There is no added value stating which 'hash' it is in the version number. The specific branch / commit used for checkout is mentioned in the .spec file as well as in .changes (even with an explanation why not using HEAD of that branch). There would not have been any objection if I'd have taken 4.0 and added 200 patches which brought it to the same level... even without mentioning git or anything else in the version (which is something that happens commonly as well: we package a 'released tarball' plus add 1, two, twenty patches from git on top. I only see value in THIS proposal for packages GENERALLY following SCM checkouts. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Adam Spiers <aspiers@suse.com> writes:

Andreas Schwab (schwab@suse.de) wrote:

...

For git you can also use the output from git describe, which is also monotonically increasing.

I'm pretty sure that's not correct. Did you test it? I think it depends on what tags the repo contains (if any), and which git describe options are being used.

If your tags are properly named then there is nothing that prevents this. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Adam Spiers <aspiers@suse.com> writes:

Please can you define "properly named"?

So they sort properly like the version. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Sascha Peilicke (speilicke@suse.com) wrote:

On 09/10/2013 02:39 PM, Andreas Schwab wrote:

...

Adam Spiers <aspiers@suse.com> writes:

...

Please can you define "properly named"?

So they sort properly like the version.

Andreas.

I guess the "if" is important here, I know (and packaged) plenty of projects which never used tags nor heard of semantic versioning or even care about. For instance, that's why all those go packages have 0.0.0+git$BLA :-)

Exactly. Even for a project that strictly follows semver, it still might have a series of tags like this: v0.1.0 v0.1.1 v0.1.2 v0.2.0 v0.2.1 v0.2.2 rel-1.0.0 rel-1.0.1 or worse ;-) IMHO the "if" is too big to rely on. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 15:58, Marguerite Su wrote:

Indeed, 1.0.0.git20130910 is smaller than 1.0.0

No it's not, because of:

Meantime in a human-being's eyes, 1.0.0.git20130910 is bigger than 1.0.0

and because of $ zypper vcmp 1.0.0.git20130910 1.0.0 1.0.0.git20130910 is newer than 1.0.0

2. "+" mostly of times means "combination"

I question that it does. It certainly does not for me. Note we are talking version numbers here, where there is more math than prose involved; therefore, '+' meaning addition/increase is more topical than agglomeration.

I think git20130910 might be good idea. you know it's from git, you know it's state, if you wanna search, github has a timestamp (although some heavy contributors may commit many times a day, but actually it's not a good habit)

The timestamp is useless as mentioned previously, as multiple commits may have the same (1s-resolution) timestamp. An offset (with or without hash, depending on what's needed) is both short and precise. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, On Tue, 10 Sep 2013, Adam Spiers wrote:

...

The timestamp is useless as mentioned previously

Mentioned by who? It's certainly not useless - it's *required* for correct chronological ordering, as I already mentioned.

You're too fixated on git. Correct chronological ordering is not depending on timestamps. It depends on some number that monotonically increases with commit time. svn revision numbers do for instance. And as timestamps indeed have the mentioned problem it's actually a bad way to ensure chronological ordering. Better than nothing I suppose, but not very good.

...

An offset (with or without hash, depending on what's needed) is both short and precise.

Sorry, I don't understand this. Can you explain in more detail?

Offset == number of commits on top of some base (where base in git describe parlance is e.g. a tag). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Adam Spiers <aspiers@suse.com> writes:

In fact, there cannot ever be a silver bullet, because if you have multiple branches being developed in tandem (e.g. stable and development) then there is no strictly defined ordering.

If they are not totally insane then the branches will have different versions. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 09/10/2013 04:59 PM, Michael Matz wrote:

Hi,

On Tue, 10 Sep 2013, Adam Spiers wrote:

...

...

The timestamp is useless as mentioned previously

Mentioned by who? It's certainly not useless - it's *required* for correct chronological ordering, as I already mentioned.

You're too fixated on git. Correct chronological ordering is not depending on timestamps. It depends on some number that monotonically increases with commit time. svn revision numbers do for instance.

And as timestamps indeed have the mentioned problem it's actually a bad way to ensure chronological ordering. Better than nothing I suppose, but not very good.

True for svn (and similar ones). Since branches are only directories here and the history is always global, revision numbers should be sufficient. However, commit timestamps should equally comply. So using both could be viewed as overkill / redundancy, but at least it wouldn't hurt in some general packaging recommendation. If possible, I'd want to avoid documenting many special cases since that would somewhat defeat the purpose of this thread. Being aware of things is certainly useful, so thanks for broadening the discussion.

...

...

An offset (with or without hash, depending on what's needed) is both short and precise.

Sorry, I don't understand this. Can you explain in more detail?

Offset == number of commits on top of some base (where base in git describe parlance is e.g. a tag).

Ciao, Michael.

-- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 15:39, Adam Spiers wrote:

...

Exactly. Even for a project that strictly follows semver, it still might have a series of tags like this:

v0.1.0 v0.1.1 v0.1.2 v0.2.0 v0.2.1 v0.2.2 rel-1.0.0 rel-1.0.1

semver does not cover *version-unrelated* prefixes/postfixes.

That was exactly my point.

If the developer of the particular software whose tags you have presented really had a change of heart and went from "v*" to "rel-*" for whatever reason, you, as the packager, should have been smart enough to recognize this and _NOT_ transplant the v*/rel-* into the RPM Version: field, just like it is done for the Linux kernel (has tag like "v3.11" but our RPM packages have 3.11 naturally). In fact, blindly transplanting whatever `git describe` tells you into Version: is almost

... almost what? But it sounds like you are making the same point I already made - git describe output is not a remotely reliable source for version ordering. The timestamp + SHA combination is deterministic and unique, sorts chronologically, is well proven (my team has been using it for 18 months), and is trivially supported by tar_scm, e.g. <service name="tar_scm" mode="disabled"> <param name="url">git://github.com/foo/bar.git</param> <param name="scm">git</param> <param name="exclude">.git</param> <param name="exclude">.gitreview</param> <param name="versionformat">1.2.3+git.%ct.%h</param> <!-- Comment this if you want the latest git master. --> <param name="revision">stable</param> </service> If you know you can trust your git tags then it can automatically extract those as the "parent" version string too, e.g. https://build.opensuse.org/package/view_file/Cloud:OpenStack:Master/openstac... The only remotely convincing argument I have heard against timestamp + SHA so far is that it generates long version strings which may cause problems with Joliet filesystems. Yes, they can also make a UI slightly uglier, but if that's a genuine issue (which I doubt) then it is trivial for the UI to trim the version components. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 17:12, Adam Spiers wrote:

...

...

you, as the packager, should have been smart enough to recognize this and _NOT_ transplant the v*/rel-* into the RPM Version: field, just like it is done for the Linux kernel (has tag like "v3.11" but our RPM packages have 3.11 naturally). In fact, blindly transplanting whatever `git describe` tells you into Version: is almost

... almost what?

almost stupid :)

Tags may be used for things other than releases (though thankfully that's rare).

It's certainly not rare in my usage, and I don't think I'm unusual. There are plenty of good reasons for using tags other than releases.

Think git://git.gitorious.org/opensuse/kernel-source which not only has "rpm-3.7.10-1.1" tags, but also "SLES11_RC2" and whatnot. If you don't watch out, it may happen that `git describe` outputs SLES11_RC2-1-g1234567 instead of the rpm-3.7.10-1.1-8-g9abcdef that you sought.

Exactly.

...

But it sounds like you are making the same point I already made - git describe output is not a remotely reliable source for version ordering.

It is, if you pay attention or trusting the tags.

?

...

The timestamp + SHA combination is deterministic and unique, sorts chronologically

Deterministic and unique, yes, but %ct is not strictly guaranteed to be strictly monotonically increasing. That is to say, you can construct a case where %ct is useless.

Interesting - please can you provide an example?

Simiarly, one can construct cases where a tag offset becomes useless. But excluding the cases where {either %ct or tag offset is uselees}, a tag offset is shorter than %ct.

What about the cases where tag offsets cannot be generated at all, due to the lack of any tags? I'm open to ideas involving tag offsets. But I'd need to see the details of a real implementation. For example, what would the _service file look like?

The longer this discussion goes on, the more I think hashes in Version: should be abolished completely. They do not sort well,

If you mean chronologically, they don't sort at all. But that's not a good reason to remove them from Version. They are needed in order to provide crucial information about which version of the source they came from. My team currently relies on this when debugging issues, and I expect the kernel team does too.

and trying to work around it with either %ct or tag offsets is just a bandaid. If the hash is gone from Version, so is the need for the sorting bandaid.

Huh?? The hash is not there to help with sorting. It's there for a completely different reason as explained above and in previous emails. So why are you saying that %ct is a workaround or bandaid for it?

Just call the f'ng Version: 1.5+git and spell out everything else in the %description. The Release: will automatically increase everytime you commit and ensure that people get the latest version your hands produced, even if there was branch-hopping or shipping an older git snapshot (a revert in essence).

Hiding important metadata in %description is going to cause problems. For example, a decent bugreport will contain version numbers of all relevant rpms involved in the bug, but it will not contain a copy'n'paste of running rpm -qi on all those rpms. So your proposed change would require a lot of developers to have to say "thanks but please can you run rpm -qai and send me the output" every time they receive a bug report. Not a good idea. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 19:05, Adam Spiers wrote:

...

It's certainly not rare in my usage, and I don't think I'm unusual.

Maybe that is prominent in the projects you look over (GNOME or something?)

Nope, I'm an XFCE guy these days ;-)

If there will never be tags for anything but marking tarballs, then trusting the tags is ok and `git describe` will always output something useful.

Sure, but that's a very brittle design. It just takes a single non-release tag to break the mechanism.

In case of suse-kernel, one may try `git describe --match="rpm-*" to limit what tags can actually be used for bases.

...

...

...

The timestamp + SHA combination is deterministic and unique, sorts chronologically

Deterministic and unique, yes, but %ct is not strictly guaranteed to be strictly monotonically increasing. That is to say, you can construct a case where %ct is useless.

Interesting - please can you provide an example?

$ GIT_COMMITTER_DATE="1970-01-01 00:00:00" git ci -m \ "Initial commit for Unix :)" [master 7db0cff] Initial commit for Unix :) 1 file changed, 1 insertion(+)

Note I how said "constructed case".

Heh :-)

You won't see it everyday, but it is possible.

Sure - but when would it *ever* happen in the real world? Let's focus on scenarios which are relevant.

Tag offsets are resistant to this (though there are other constructible cases where they become useless).

Right. Like I said above, someone creating a non-release tag without realising it would break the packaging mechanism is a very likely scenario. Someone explicitly setting GIT_COMMITTER_DATE is somewhat less likely :-)

...

...

Simiarly, one can construct cases where a tag offset becomes useless. But excluding the cases where {either %ct or tag offset is uselees}, a tag offset is shorter than %ct.

What about the cases where tag offsets cannot be generated at all, due to the lack of any tags?

I'll just quote the thing I recently placed into the wiki and already used in a number of (upstream-)nascent packages:

"""an alternative monotonically increasing identifier can be obtained by using the history root as a base (`git rev-list 9265358 | wc -l`), useful for when a project is in such an early stage that there have not been any releases yet (Version: 0~git123)."""

That's not a bad idea. Pull requests to tar_scm are welcome.

...

...

and trying to work around it with either %ct or tag offsets is just a bandaid. If the hash is gone from Version, so is the need for the sorting bandaid.

Huh?? The hash is not there to help with sorting.

The hash does not contribute to sortability. %ct is a bandaid for ensuring sorting order. Tag offset is a bandaid for ensuring sorting order.

That's like saying cars are a bandaid for ensuring quicker transport.

Move the hash from Version to Description, and you will no longer need the bandaid.

That doesn't make any sense. Moving the hash to %description wouldn't affect the ordering at all. You still need something to order versions.

But I do accept your argument that telling users in a second step to re-run `rpm -qi` may be asking too much of them.

So it seems we are to live with sorting bandaids :p

They're not bandaids, because they're not fixing anything which is broken. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Křištof Želechovski (giecrilj@stegny.2a.pl) wrote:

Dnia wtorek, 10 września 2013 18:05:42 Adam Spiers pisze:

...

Jan Engelhardt (jengelh@inai.de) wrote:

...

Just call the f'ng Version: 1.5+git and spell out everything else in the %description. The Release: will automatically increase everytime you commit and ensure that people get the latest version your hands produced, even if there was branch-hopping or shipping an older git snapshot (a revert in essence).

Hiding important metadata in %description is going to cause problems. For example, a decent bugreport will contain version numbers of all relevant rpms involved in the bug, but it will not contain a copy'n'paste of running rpm -qi on all those rpms. So your proposed change would require a lot of developers to have to say "thanks but please can you run rpm -qai and send me the output" every time they receive a bug report. Not a good idea.

The bug report will contain version numbers and release numbers. Developers can recover the exact source from the release number, can't they?

Nope, the release number is controlled entirely by OBS. If someone updates the git tarball without modifying the version number, the only way to find out would be to connect to the host in question (assuming that's possible) and run rpm -qi on the relevant packages. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 16:24, Togan Muftuoglu wrote:

For example I maintain nightly builds for darktable for a long time and this is what I use

dt_ver=$(git describe --tags HEAD | sed 's,^release-,,;s,-,_,;s,-,_,;') which results

1.3_929_g6202a15 and the respective field in the spec is Version: %{dt_ver}_git

Interesting case - that can blow up when darktable releases a hypothetical "1.3.1". That is because 1.3.1_1024 < 1.3_929 Like http://en.opensuse.org/openSUSE:Package_naming_guidelines suggests, the SCM identifier ("git") should be *before* the SCM ids. IOW, Version: 1.3_git929_g6202a15 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

It's just an alternative. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Follow the thread. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Tue, 10 Sep 2013 13:20:51 +0100 Adam Spiers <aspiers@suse.com> пишет:

Andreas Schwab (schwab@suse.de) wrote:

...

For git you can also use the output from git describe, which is also monotonically increasing.

I'm pretty sure that's not correct. Did you test it? I think it depends on what tags the repo contains (if any), and which git describe options are being used.

Well ... if version V has commit V_C, then V-$(git rev-list --oneline --count V_C..HEAD)-g$(git log -n 1 --format=%h HEAD) should give the same result but without relying on tags, should not it? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Richard Biener (rguenther@suse.de) wrote:

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Surely you can just wait for 4.8.2? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting Sascha Peilicke <speilicke@suse.com>:

On 09/10/2013 02:38 PM, Adam Spiers wrote:

...

Richard Biener (rguenther@suse.de) wrote:

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

That would make poor little kittens cry. But it's not disliked by our policies, so you could do that. "Forever" is such a relative term :-)

Isn't it? But is it understood by Zypper/Libzypp ? And take this into account from rpm.org: Solution Number 2: Just Say No! If you have the option between changing the software's version-numbering scheme, or using epoch numbers in RPM, please consider changing the version-numbering scheme. Chances are, if RPM can't figure it out, most of the people using your software can't, either. But in case you aren't the author of the software you're packaging, and its version numbering scheme is giving RPM fits, the epoch tag can help you out. it is purely NOT advised to use epochs.. especially not if it's just for cosmetic changes. And we DO accept the fact that zypper dup might have to downgrade once in a while. And if you want old stories: please re-read http://lists.opensuse.org/opensuse-packaging/2009-01/msg00090.html Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 14:25, Richard Biener wrote:

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

zypper dup will do it without epochs - and there is a dup coming every 8 months.. or so.

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

"Wait for gcc49" :) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Le mardi 10 septembre 2013 à 14:25 +0200, Richard Biener a écrit :

On Tue, 10 Sep 2013, Sascha Peilicke wrote:

...

Hi guys,

I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file:

Version: 1.2.3

So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand:

1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right?

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ? -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Le mardi 10 septembre 2013 à 16:02 +0200, Jan Engelhardt a écrit :

On Tuesday 2013-09-10 15:28, Frederic Crozat wrote:

...

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ?

Yes, but not applicable in this case. Remember the sort order:

4.8.1~s < 4.8.1 < 4.8.1_s < 4.8.1_2

Hmm, usually, I tend to use git checkout (or any other vcs checkout) before a particular release is out, so 4.8.1~s is ok. But now, I understand it doesn't handle all the options :( -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 10 Sep 2013, Michael Schroeder wrote:

On Tue, Sep 10, 2013 at 04:05:34PM +0200, Frederic Crozat wrote:

...

Le mardi 10 septembre 2013 ? 16:02 +0200, Jan Engelhardt a ?crit :

...

On Tuesday 2013-09-10 15:28, Frederic Crozat wrote:

...

...

One extra issue is to ensure upgradeability of whatever existing scheme is in use to the new scheme. rpm epoch anyone? ;)

I've been relucant to change gcc from using gcc48-4.8.1_20130909 to gcc48-4.8.1_202388 for that reason. Unfortunately gcc48-4.8.1_20130909 is not upgradeable to gcc48-4.8.1_svn202388 so I have to wait for GCCs svn revision to increase beyond 20130909 ;) Or use a different separator (+ and . match _ but - would be newer).

Don't we have '~' separator in RPM to support this kind of versioning now ?

Yes, but not applicable in this case. Remember the sort order:

4.8.1~s < 4.8.1 < 4.8.1_s < 4.8.1_2

Hmm, usually, I tend to use git checkout (or any other vcs checkout) before a particular release is out, so 4.8.1~s is ok.

But now, I understand it doesn't handle all the options :(

You just have to wait until 4.8.2 if you want to introduce a new numbering scheme ;)

Or completely alternative to this whole scheme just package a diff alongside a released tarball. Bonus: you get the possibility of being able to verify its contents with an available signature. Bonus 2: less load on the source server(?) Bonus 3: easier to see what the changes since a release are. Oh, and then provide incremental diffs whenever you update the package rather than exchanging the diff. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 11 Sep 2013, Adam Spiers wrote:

Richard Biener (rguenther@suse.de) wrote:

...

Or completely alternative to this whole scheme just package a diff alongside a released tarball.

Nice thinking outside the box :-)

...

Bonus: you get the possibility of being able to verify its contents with an available signature.

I don't understand this point. You mean verify the contents of the released tarball? But if the diff is not also verified then isn't that rather pointless? Also, a git hash is equivalent to an integrity check (albeit an unsigned one).

Yes, verify the contents of the released tarball. SCMs other than git don't have that hash as integrity check.

...

Bonus 2: less load on the source server(?)

tar_scm caches, so I'm not sure that argument's too compelling.

I mean the source server stores each and every file that ever was in any source package. So if you update the tarball many times the source server ends up storing each tarball forever. Just adding (or updating) a patch should be cheaper. It may be that with source services the tarballs are not stored permanently(?) but only cached (and the cache is garbage collected). Of course that would have issues with digging up old revisions of packages if the source used in the source service vanishes.

...

Bonus 3: easier to see what the changes since a release are.

Easier for who? Only for packagers, and excluding the one who packaged the diff (since they already had to have a clone of the repo in order to make the diff in the first place). So again, not hugely compelling IMHO.

Well, for GCC for example you at the moment get changes like Mon Sep 9 11:56:02 UTC 2013 - rguenther@suse.com - Update to gcc-4_8-branch head (r202388). - Backports regression fixes for all architectures. * includes changes in aarch64-pthread-option.patch and simply the source tarball exchanged. If I'd have packed a diff from the last update (r201525) you can easily browse that for malicious changes (given the source tarball would be digitally signed and verified). Of course one reason that I wouldn't accept outside submitrequests that update the source tarball ;) Don't trust anybody but myself.

...

Oh, and then provide incremental diffs whenever you update the package rather than exchanging the diff.

In the absence of a source service to do this (which I suspect would be quite hard to write), I think it will create a lot more work for the packager :-/

Not sure - I have a script to update the GCC package to a SVN revision and I never used source services. A source service to provide a diff between a previous revision and head (or between two revisions) shouldn't be terribly hard to write though (no, I'm not volunteering ;)). Richard. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 11 Sep 2013, Adam Spiers wrote:

Richard Biener (rguenther@suse.de) wrote:

...

On Wed, 11 Sep 2013, Adam Spiers wrote:

...

Richard Biener (rguenther@suse.de) wrote:

...

Or completely alternative to this whole scheme just package a diff alongside a released tarball.

Nice thinking outside the box :-)

...

Bonus: you get the possibility of being able to verify its contents with an available signature.

I don't understand this point. You mean verify the contents of the released tarball? But if the diff is not also verified then isn't that rather pointless? Also, a git hash is equivalent to an integrity check (albeit an unsigned one).

Yes, verify the contents of the released tarball. SCMs other than git don't have that hash as integrity check.

IIRC mercurial and monotone do, at least. And probably bzr too.

...

...

...

Bonus 2: less load on the source server(?)

tar_scm caches, so I'm not sure that argument's too compelling.

I mean the source server stores each and every file that ever was in any source package.

Sounds like you're more familiar with the OBS server-side implementation than me. Are you saying that for every single tarball uploaded, OBS keeps an unpacked version server-side? That surprises me, because I know that it keeps the *packed* version, and keeping both seems very wasteful (except if the unpacked version was part of a cache).

I think it only keeps the (compressed) tarball.

...

So if you update the tarball many times the source server ends up storing each tarball forever. Just adding (or updating) a patch should be cheaper.

I think that would probably depend on the size of the tarballs, the size of the patches, and the frequency of updates. Uncompressed patches can be quite wasteful too.

Oh, of course. For example the gcc 4.8.0 -> 4.8.1 diff is 1.7MB compressed while the tarball is 84MB compressed. And I believe rpm handles compressed patches (or the source service has compressed storage maybe) Changes on non-release branches are much larger though.

...

It may be that with source services the tarballs are not stored permanently(?) but only cached (and the cache is garbage collected). Of course that would have issues with digging up old revisions of packages if the source used in the source service vanishes.

Don't forget that source services can be client-side-only, via disabledrun mode.

...

...

...

Bonus 3: easier to see what the changes since a release are.

Easier for who? Only for packagers, and excluding the one who packaged the diff (since they already had to have a clone of the repo in order to make the diff in the first place). So again, not hugely compelling IMHO.

Well, for GCC for example you at the moment get changes like

Mon Sep 9 11:56:02 UTC 2013 - rguenther@suse.com

- Update to gcc-4_8-branch head (r202388). - Backports regression fixes for all architectures. * includes changes in aarch64-pthread-option.patch

and simply the source tarball exchanged. If I'd have packed a diff from the last update (r201525) you can easily browse that for malicious changes (given the source tarball would be digitally signed and verified).

Of course one reason that I wouldn't accept outside submitrequests that update the source tarball ;) Don't trust anybody but myself.

Well, that's another good reason to avoid using an SCM which doesn't have integrity built into the design :-)

Heh - if only changing the SCM of a project was easy ... Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 10 of September 2013 15:37EN, Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Michal Kubeček <mkubecek@suse.cz>:

...

This could lead to unexpected results. Recently I found that RPM version comparison algorithm can be quite counter-intuitive when underscores are used as separators. In particular,

1.1.1_3.0.13_0.27-3.1 < 1_3.0.13_0.27-0.17.15

even if 1 < 1.1.1

That one is indeed a bit surprising.. but zypper confirms:

...

zypper vcmp 1.1.1_3.0.13_0.27-3.1 1_3.0.13_0.27-0.17.15

1.1.1_3.0.13_0.27-3.1 is older than 1_3.0.13_0.27-0.17.15

the 'rule of thumb' is that _ is being substituted with '.' as well as a '.' is added between numerical and alpha chars (hence: 1a == 1.a)

...

zypper vcmp 1a 1.a

1a matches 1.a

One problem with this is that it makes the way we are constructing KMP version strings rather fragile. As soon as module versions keep the same number of components, e.g. 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1.0 -> 1.1.1 -> ... you are safe. But once you try 1 -> 1.1 you are in trouble. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 15:56, Michael Schroeder wrote:

On Tue, Sep 10, 2013 at 03:46:57PM +0200, Michal Kube??ek wrote:

...

One problem with this is that it makes the way we are constructing KMP version strings rather fragile. As soon as module versions keep the same number of components, e.g.

1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1.0 -> 1.1.1 -> ...

you are safe. But once you try

1 -> 1.1

you are in trouble.

I think that you could (mis-)use the ~ comparison mechanism for this provided by newer rpm versions:

Which is something I suggested as early as https://bugzilla.novell.com/show_bug.cgi?id=540558 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 3:24 PM, Jan Engelhardt <jengelh@inai.de> wrote:

On Tuesday 2013-09-10 20:20, Claudio Freire wrote:

...

Since you have the hash, you don't even need more than day precision

Since you have the hash, you don't need *anything else* per se except so as to please the package manager.

So, if it's there to please a human, then it's all the more important to have it human-readable right? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 3:44 PM, Adam Spiers <aspiers@suse.com> wrote:

Claudio Freire (klaussfreire@gmail.com) wrote:

...

On Tue, Sep 10, 2013 at 3:24 PM, Jan Engelhardt <jengelh@inai.de> wrote:

...

On Tuesday 2013-09-10 20:20, Claudio Freire wrote:

...

Since you have the hash, you don't even need more than day precision

Since you have the hash, you don't need *anything else* per se except so as to please the package manager.

So, if it's there to please a human, then it's all the more important to have it human-readable right?

It's not there to please a human. Please read the rest of the thread.

Unbelievable as it may be, I read the whole thread. The point is sortability, and ISO fulfills it. There's an ISO format without separators too, btw. ISO adds human readability to sortability. The only possible ambiguities ISO adds, are timezone-related. But unless you expect to be releasing several times a day, day precision should be enough, and you thus avoid timezones. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Sep 11, 2013 at 3:13 AM, Adam Spiers <aspiers@suse.com> wrote:

It's not unbelievable. But you said "if it's there to please a human" when I've stated several times that it's there to make libzypp-based upgrades work, so it was a reasonable assumption that you hadn't read it.

Thanks Adam! Sorry for the noise created by me. Good Night Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Claudio Freire (klaussfreire@gmail.com) wrote:

On Tue, Sep 10, 2013 at 8:22 AM, Sascha Peilicke <speilicke@suse.com> wrote:

...

5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

Is that a unix timestamp?

IMHO, that's horribly unreadable for any human. What's wrong with ISO?

ISO contains hyphens, which is incompatible with rpm versions.

Since you have the hash, you don't even need more than day precision,

Incorrect - it's there for sorting to ensure libzypp knows which package is newer.

Being able to tell the release date from the version number without aid from a python console would be good, IMHO.

I agree, but that would make it even longer, and people are already complaining about the length. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 20:43, Adam Spiers wrote:

...

...

Is that a unix timestamp? IMHO, that's horribly unreadable for any human. What's wrong with ISO?

ISO contains hyphens, which is incompatible with rpm versions.

YYYYMMDD is a permitted hyphenless format of ISO 8601, (says Wikipedia).

Cool, I didn't know that. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Yamaban (foerster@lisas.de) wrote:

On Tue, 10 Sep 2013 20:43, Adam Spiers <aspiers@...> wrote:

...

Claudio Freire (klaussfreire@gmail.com) wrote:

...

On Tue, Sep 10, 2013 at 8:22 AM, Sascha Peilicke <speilicke@suse.com> wrote:

...

5) X+git.1363873583.8dfab15

Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability.

Is that a unix timestamp?

IMHO, that's horribly unreadable for any human. What's wrong with ISO?

ISO contains hyphens, which is incompatible with rpm versions.

I'd prefer something a little different than 5.), let's call it 6.

6.) X+{date}.{scm}{commit} with: {date} as %Y%m%d = YYYYmmdd followed by (dot), {scm} as one of {git,svn,bzr,hg,cvs,...}, and {commit} as scm-specific commit tag / hash / whatever

Pro: readability, sortability (at least days work for sure)

It's not good enough to be sortable to the resolution of one day. Yes, people do actually built multiple versions per day sometimes, and build bots do even more regularly.

Contra: can be long

Right. Personally I like the timestamp legibility and the length doesn't bother me, but it seems to bother one or two others at least. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Marguerite Su (i@marguerite.su) wrote:

Hi, guys,

You are diving too deep that I can't quite follow even by reading the whole thread...

I just need some clearance:

Will this be (possibly) a RFC that appears on wiki and limits all packagers?

Sorry, I thought I answered that already but can't find my reply now. I think the goal is to clarify this page: http://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_v... Notice this page is a set of guidelines not rules. And the section we are talking about concerns SCM snapshots, not packaging of official release tarballs.

Or you were just talking about OBS coding/automatic packaging eg tar_scm backend

Yes, this is mainly about tar_scm, because it would be very tedious to assign timestamps and commit hashes / numbers by hand.

If it's a RFC, do our packagers need attending a codeschool tutorial before fetching from svn/git?

No, tar_scm makes it easy to do without knowing svn / git / hg / bzr.

You know, many of us just learned `svn co` and `git clone`...

And I see you talked the importance of "hashes", now I know by using it everything else is not needed.

In the git case, having hashes in the version string is very useful because it makes it easy to tell exactly which version of the git source the package came from. This is very important in debugging, for example.

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

Why is that a problem, and where? You mentioned before that it is shown in UIs, but the UI could easily hide the hash if it wanted to.

Or we just want users get the idea "wow it's from svn/git. wow it's a dev version"

Most users except power users don't usually care much about the version number. A UI can choose how much or little of the $VERSION-$RELEASE string to expose. But usually it will make sense to expose either all of it, or none of it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Marguerite Su (i@marguerite.su) wrote:

On Wed, Sep 11, 2013 at 3:39 AM, Adam Spiers <aspiers@suse.com> wrote:

...

...

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

Why is that a problem, and where? You mentioned before that it is shown in UIs, but the UI could easily hide the hash if it wanted to.

Yes...sorry, I think the situation that user-experience-concern guys and tech-detail-concern guys talking together loudly just make we misunderstand each other.

Yeah maybe :)

My original idea was that version number will be shown to users in YaST.

That's how it is currently - right?

So users seeing a random string will not get a clear view of what we just want to ship.

They can just judge by the svn/git prefix to get an idea that this version is a dev version.

Because a "random string" is meaningless if they don't know the tech details behind it.

But the "random string" is only the last part of the version string. The "normal" part would still be there. E.g. package-name-1.7.3+git.1378133004.9e149b8-11.1

...

...

Or we just want users get the idea "wow it's from svn/git. wow it's a dev version"

That might be useful to some users.

...

Most users except power users don't usually care much about the version number. A UI can choose how much or little of the $VERSION-$RELEASE string to expose. But usually it will make sense to expose either all of it, or none of it.

Yes...but they still want to know if they're installing a newer version or older version,

unless YaST can tell them by color diff.

eg, if you install fcitx-4.2.8.git20130911, you know it is newer than fcitx-4.2.8.git20130910

But if it is fcitx-4.2.8.git.aldjfad and fcitx-4.2.8.git.wueouqp, they just don't know what you are trying to telling them.

Exactly, and that's why I think it's important to have the date: package-name-1.7.3+git.1378133004.9e149b8-11.1 is obviously older than package-name-1.7.3+git.1378134719.8b662d0-6.1 Using an ISO format would make this even more obvious: package-name-1.7.3+git.20130902T154324.9e149b8-11.1 package-name-1.7.3+git.20130902T161159.8b662d0-6.1 But it's not just to make it clear for users. It's so that libzypp can tell, which is even more important.

My theory just comes from the fact that Arch linux changed all its network interfaces to random strings, eg: wlan0 is not wlan0, is wlanjlajl. So now users just know it's a wlan, they can't even search an answer through by Google because everyone's interface is now different.

None of these schemes suffer from this problem, because they still have the same "package-name-1.7.3" prefix. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 2013-09-10 21:39, Adam Spiers wrote:

...

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

Why is that a problem, and where? You mentioned before that it is shown in UIs, but the UI could easily hide the hash if it wanted to.

There is no way for an UI to reliably tell whether a given part of %version is a hash or not as long as %version is a plaintext non-markup string. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 4:19 PM, Marguerite Su <i@marguerite.su> wrote:

But version number will be shown to all instead of just us...to most of the people (including me unluckily), hashes is just a random string at the very first glance.

And the very second and the very third. TBH, hashes don't mean anything except to the developers of the package. And, TBH, only when debugging, and only with the aid of developer tools. Because I'm a developer and I can't stand hashes in any other context (ie: reverting to a hash, or reading a git log with hashes instead of releases, confuses the hell out of me). But to *them*, **when debugging**, it means something very specific and very useful. So I can put up with them being on the version string, since it entails tangible benefits during bug hunting. And it's not the timestamp that makes the version string long. It's the hashes. Typical git hashes are 160-bits long. That's 40 hex digits. That's a lot more than is shown on that example on the OP. Unless the proposal is to put the last N digits of the hash? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 5:09 PM, Adam Spiers <aspiers@suse.com> wrote:

...

And it's not the timestamp that makes the version string long. It's the hashes. Typical git hashes are 160-bits long. That's 40 hex digits. That's a lot more than is shown on that example on the OP. Unless the proposal is to put the last N digits of the hash?

Of course! 40 bytes would be idiotic. Sascha's original post proposed using the abbreviated commit hash ("%h" in git log) which is only 7 bytes - are you *sure* you read the whole thread? ;-P

http://lists.opensuse.org/opensuse-packaging/2013-09/msg00035.html

Yes, but it's not clear whether it's just an example or use of an abbreviated form is implicit. Except for mercurial that I use at work, I'm pretty much a git noob, so I don't know whether it has a standard abbreviated form or not and so can't assume one way or the other. Btw, looking at tar_scm's code in conjunction with man git ;) , the format string alone cannot enable second-precision ISO dates, since --date=short is hardcoded on the command line. Thus the patch gets bigger. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Sep 10, 2013 at 6:06 PM, Adam Spiers <aspiers@suse.com> wrote:

$ git log -n1 --date=short --pretty=format:%ci 2013-09-02 14:00:14 +0100

So in fact that --date=short probably doesn't have any effect and maybe it could be removed.

Um... that timezone part also looks like it would be troublesome -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Yamaban (foerster@lisas.de) wrote:

On Tue, 10 Sep 2013 23:08, Claudio Freire <klaussfreire@...> wrote:

...

On Tue, Sep 10, 2013 at 6:06 PM, Adam Spiers <aspiers@suse.com> wrote:

...

$ git log -n1 --date=short --pretty=format:%ci 2013-09-02 14:00:14 +0100

So in fact that --date=short probably doesn't have any effect and maybe it could be removed.

Um... that timezone part also looks like it would be troublesome

Yep! Enforcing UTC is a MUST have, anything else is plain stupid.

Agreed. Like I said, pull requests to tar_scm are very welcome (as long as they modify the test suite correspondingly). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt (jengelh@inai.de) wrote:

On Tuesday 2013-09-10 22:09, Adam Spiers wrote:

...

...

And it's not the timestamp that makes the version string long. It's the hashes. Typical git hashes are 160-bits long. That's 40 hex digits. That's a lot more than is shown on that example on the OP. Unless the proposal is to put the last N digits of the hash?

Of course! 40 bytes would be idiotic. Sascha's original post proposed using the abbreviated commit hash ("%h" in git log) which is only 7 bytes - are you *sure* you read the whole thread? ;-P

The length of %h is actually: as many hexdigits as are needed to uniquely identify it, or 7 hexdigits, whichever of the two is longer. The Linux kernel, due to the mass of commits in it, already has a not insignificant amount (>1%) of 8-character %h IDs.

Good to know, thanks. But even 8 or 9 bytes is better than 40 ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org