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