Mailinglist Archive: opensuse-packaging (155 mails)

< Previous Next >
Re: [opensuse-packaging] Re: Proper version scheme for packages from git, hg, svn, ...
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Fri, 10 Jan 2014 23:40:02 +0000
  • Message-id: <20140110234002.GE29207@pacific.linksys.moosehall>
Jan Engelhardt (jengelh@xxxxxxx) 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:

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

* 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:

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.

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups