On 09/10/2013 01:52 PM, Adam Spiers wrote:
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.
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. We achieved setting a global standard for the License: tag (well, who argues with legal :-), having sth. similar for Version: can't hurt. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)