Re: okteta

[Greg Troxel <gdt%lexort.com@localhost>]

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

>> 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.

I had not heard of FreeBSD ports doing this.  I assume epoch is the most
significant component of version, basically incremented when an update
would go backwards, and is hidden from the user and used to get correct
sorting?

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

That and a wrong version, but yes.

> 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

I think it's a simple matter of someone producing a patch for epoch.  I
am not aware of any real objections to doing this in a way with
semantics that match the other systems.

Whether to prohibit going backwards or prohibit having a versions that
doesn't match upstream is an unresolvable matter of judgement.  At
least, it's easier to code up epoch numbers than to resolve it!

> 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 think pkgin just got SUPERSEDES support, where a package can express
that it is the successor of some previous package.

I don't clearly see this fitting in pkg_add conceptually, as that
operates on individual packages.  Although probably one would be able to
do a pkg_add -u operation with an arg of a binary package with
SUPERCEDES and have it find the old one.    I suspect that is not
controversial and just ENOPATCH.

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

I think it is merely ENOPATCH.