You are not logged in.
I am the maintainer for vim-diffchar. Upstream just upgraded from 7.32 to 7.4. However, pacman thus considers the new version to be earlier than the previous version. Is the only way to handle this by bumping the epoch in the PKGBUILD? My problem with this is that I'd have to bump the epoch regularly, if upstream continues with this versioning scheme, but I can't see any other way to fix the PKGBUILD.
Last edited by Salkay (2017-12-31 22:58:19)
Offline
Unfortunately there's not much you can do retrospectively. You could vet the releases, adding a minor version to the pkgver where appropriate (e.g. instead of 7.32, use 7.3.2) and either store the upstream version in a variable, or use string manipulation to remove the extra period where necessary. Bumping the epoch would be easier and less misleading to the end users though.
The best thing to do, imo, would be to talk to upstream and ask them to use a more sane versioning scheme.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Online
Bumping the epoch would be easier and less misleading to the end users though.
I agree for the isolated case this would be good, but as this is likely to continue, this could get messy: the epoch number would basically become the version number.
Looking at the upstream version numbers it's almost always X.Y except in a few cases I could only speculate that he was drunk typing and added an extra digit X.YZ, but X.Y is always still sequential. With all existing versions, you could just trim to 2 digits (X.Y) and everything would work, but to deal with the potential of these seemingly random digits eventually becoming meaningful, you could right-pad with zeros: so 6.4 becomes 6.40 which is greater than 6.32. This would work with all the existing version number of this package, and would work with extension of the current trend.
This would be much like WorMzy's idea of adding a period, except that you'd have to go back and change 6.32 to 6.3.2 which you can't do. Right padding with a zero requires no retroactive changes: just submit 6.40 to the AUR now.
(edit: s/to/no/)
Last edited by Trilby (2017-12-31 23:11:44)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Thank you both for your replies.
The best thing to do, imo, would be to talk to upstream and ask them to use a more sane versioning scheme.
Probably a good idea, although upstream has been a bit unresponsive, not answering a request to add a licence from 1.5 years ago.
I agree with WorMzy, in that adding a minor version would be confusing. But I also agree with Trilby that continually bumping the epoch is messy.
I've decided to go with Trilby's suggestion of right padding with zeros. I feel like this is consistent with what upstream means by 6.4 anyway. It's still a bit deceptive to the end user, but works well enough. Thanks again.
Offline
I've decided to go with Trilby's suggestion of right padding with zeros. I feel like this is consistent with what upstream means by 6.4 anyway. It's still a bit deceptive to the end user, but works well enough. Thanks again.
If you find it deceptive, then you can probably add the real version in the description. I'm not completely sure if the AUR policy allows that, though.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
If you find it deceptive, then you can probably add the real version in the description. I'm not completely sure if the AUR policy allows that, though.
Good idea. I'll keep it in mind if this problem recurs. Thanks.
Offline