Re: 2008Q1 -> current: downgrade

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Tue, May 06, 2008 at 10:03:20AM +0200, Alan Barrett wrote:
> On Mon, 05 May 2008, Alistair Crooks wrote:
>     [upstream package version "0.14.2" is newer than version "20080220",
>      although the number is smaller]
> > > FreeBSD addressed this by adding an "epoch" counter [...]
> > > 
> > > For example, instead of going from "stgit-20080220" to "stgit-0.14.2"
> > > one could go to "stgit-0.14.2,1", where the trailing ",1" means
> > > "numbering has gone backwards once".
> > 
> > We don't have the means to do that right now, and retrofitting it onto
> > the ordering mechanism which we use right across pkgsrc would not be
> > easy, simple or even desired
> 
> I haven't tried to do it, but I don't think it would be too difficult.
> Add PKGEPOCH=1 to the pkg Makefile; Use that to append ",1" to
> the version number, in much the same way as we currently map from
> PKGREVISION=5 to "nb5"; and change any code that compares package
> revisions to know about the new scheme.

Right.
 
> > (I don't know what the ,1 is meant to signify, even with your
> > excellent explanation, and I don't see how this ordering even works).
> 
> Conceptually, it's just an extra component of the version number, with
> a higher precendence than any other component.  This extra component is
> assigned by pkgsrc, to work around problems introduced by the upstream
> source; whenever the upstream makes their numbering go backwards (that
> is, releases a new version whose number is smaller than that of the
> old version), pkgsrc says "You can't trick us so easily, we'll just
> increment this extra component that has a higher precedence".

Right.

But what's confusing me is that this epoch has a higher precedence, and
yet it's tagged onto the end of the version number. Straight away, that
has ordering implications, is counter-intuitive, and is unlikely to
fly long term.

Secondly, the epoch number is meant to represent that the version number 
has taken the equivalent of a "reset" some time in the past. When did it
take the reset? The epoch number adds nothing to that.

In fact, it's only in replying to this email that it has suddenly
struck me what you're trying to do with epoch.  Now maybe I'm being
slow today, but that's not a good sign in general - I mean, I used to
know some things about this part of the system, but this has taken a
while to sink in.
 
> T0: upstream releases foo version "20080220".
> T1: pkgsrc packages it, as foo-20080220
> T2: pkgsrc patches it; now we have foo-20080220nb1
> T3: upstream releases version 0.14.2; upstream thinks 0.14.2 > 20080220
> T4: pkgsrc thinks 0.14.2 < 20080220, which is no good.  So we can't
>     package it, or we have to change the way we package it, or live
>     with some bad effects.
> T5: pkgsrc grows the "epoch" capability.  All version number comparisons
>     get taught that the "epoch" value has a higher precedence than
>     other parts of the version number, so "0.14.2,1" and "20080220"
>     are compared almost as if they had been "1.0.14.2" and "0.20080220".
> T6: pkgsrc can now package foo-0.14.2,1
> T7: pkgsrc patches the package, and it becomes foo-0.14.2nb1,1

OK, that's a lot clearer now - thanks for the explanation.

Right, I can see the need, how it works, and the technical aspects
of this.  It still needs to be at the head of the version number.
To be tagged at the end means it has lower precedence than the version
number itself.

i.e. 0.14.2,1 above needs to become 1<sep>0.14.2. A missing epoch
number and separator means the epoch defaults to 0 for the epoch.
 
> > I'd be more inclined to use a different PKGBASE for the affected
> > packages.
> 
> Yes, that's also possible, but I prefer keeping the same PKGBASE.

So I need to ask - how common is this? I can think of a few occasions
in the last 10 years where this has happened, but not many. Why would
a version numbering scheme reset itself without the PKGBASE changing?

Is it wise to penalise the rest of the pkgsrc base with handling for
a few packages, when a workaround exists?

I always prefer to optimise for the most common cases, not the few
that break the rules.

Regards,
Alistair