Mailinglist Archive: opensuse-packaging (155 mails)

< Previous Next >
Re: [opensuse-packaging] Re: Proper version scheme for packages from git, hg, svn, ...
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Sat, 11 Jan 2014 16:14:21 +0000
  • Message-id: <20140111161421.GE13009@pacific.linksys.moosehall>
Jan Engelhardt (jengelh@xxxxxxx) 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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >