Re: okteta

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Sun, 20 Aug 2023 10:10:17 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost> writes:
> 
> >> Date: Sun, 20 Aug 2023 15:32:52 +1200
> >> From: Mark Davies <mark%ecs.vuw.ac.nz@localhost>
> >> 
> >> The very old kde4 version of okteta in pkgsrc is version 4.14.3nb36.
> >> The latest version (in pkgsrc-wip) is 0.26.12
> >> 
> >> Should I just update it in pkgsrc and have the version number go 
> >> backwards or does someone have a better suggestion?
> >
> > Maybe if the kde4 version was 4.*, and this is the version in kde5, it
> > should be imported as 5.0.26.12?
> 
> Maybe, but if upstream has really gone backwards, I tend to think that
> just following upstream and there is some mess and then it's ok is
> preferable to having continuing "why is this version different than in
> every other packaging system -- is it really the same".
> 
> So I would  see what Fedora, Debian, FreeBSD Ports do.

They all use an epoch number.

We don't have epoch numbers, but what I suggested would conveniently
have the same effect.

I think we should put more effort toward making automatic updates DTRT
rather than make users silently get stuck on old versions just because
the `newer' version looks more aesthetically pleasing.

Indeed, I would rather go further and abolish the practice of
reversing version numbering without epoch numbers, and the related
practice of renaming packages without a transitional package to enable
pkg_add or pkgin to automatically discover it needs to track the new
one.

(I'm still not clear on why we don't have epoch numbers in pkgsrc.)