Re: 2008Q1 -> current: downgrade

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

On Wed, May 21, 2008 at 02:23:11PM +0200, Dieter Baron wrote:
> In article <20080521121023.GB873%apb-laptoy.apb.alt.za@localhost> Alan wrote:
> : On Wed, 21 May 2008, Alistair Crooks wrote:
> : > I wanted to know when we'd use epoch, and have only had hand-waving
> : > answers.
> 
>   Sorry, but this has been answered, quite detailed, more than once in
> this thread: When a newer release uses a version number that
> dewey-compare would consider lower than the old version (e.g. when
> going from dates to N.M).
> 
>   This is a real problem for which we currently have no solution, and
> here a simple, low-effort solution is suggested.

My point was that we have come 11 years in pkgsrc with very few
requirements for this functionality.  Suddenly it has become
absolutely critical and essential to have it now, to address this
"real problem". I have outlined a workaround for the (as I see it)
rare occasions when this would be used; to characterise that as
"no solution" is unfair, I believe.

>   What is needed, roughly, is:
> 
> - default PKGEPOCH to 0
> - prepend $PKGEPOCH<separator> to version if $PKGEPOCH > 0
> - teach dewey compare about epoch
> 
>   I'm sure this can be implemented, tested and documented in under two
> hours.
> 
> 
>   Your reservations about this approach, on the other hand, seem
> rather hand-wavy to me.  What, exactly and in detail, are your
> objections?

My objection is that this is overkill, unnecessary, unwanted by some,
and can be worked around. My hands have stopped waving now.

And can you tell me when this epoch would have been used in the past 5
years, please?

> : > I don't feel it's prudent to do this to every package for just a small
> : > number of packages over the last 10 years which can be worked around.
> 
> : I don't understand your point about doing this to every package.
> : Most packages won't change at all.  If we had had a scheme like this
> : throughout the last 10 years, then only a small number of packages would
> : have been affected during that time.
> 
>   Exactly; in much the same way as is done for PKGREVISION now.  If a
> package doesnt need it, it uses the default of 0, with no effort and
> no visible clutter in either the Makefile or the resulting version
> number, and no change from existing behaviour.

My view is that the more bells and whistles we grow in pkgsrc, the
more features that are added, the extra switches for this and that -
they diminish from the whole picture, not add to it.  The aim is
simplicity, not big honking lists of things we can do but probably
won't.  A switch that's used once every 5 years seems to come into
that category.

Thanks,
Al

PS.  (Off topic, so I left it as a postscript) Since when has NetBSD
had its own version of awk?