On Sat, Oct 20, 2018 at 21:01:56 -0400, Eli Schwartz via aur-general wrote:
On 10/20/18 7:51 AM, Tinu Weber wrote:
On Sat, Oct 20, 2018 at 12:11:04 +0100, Jonathon Fernyhough wrote:
On 20/10/2018 03:05, hagar wrote:
Because of the Maintainers increasing pkgrel I was considering increasing the pkgrel by 0.01 each new build.
This would allow for 99 subsequent builds on each pkgrel.
The docs say that it can be of type ver.subver.
would this work?
I use this approach when rebuilding any archlinux32 packages for manjaro32. arch32 builds Arch PKGBUILDs with a "tenths" pkgrel bump (1 -> 1.0, 1.1 etc.), so for any of my rebuilds I add a "thousandths" bump (1.0 -> 1.01 etc.).
Wouldn't that be a "hundredth"? :-P
Joke aside, vercmp seems to cope fine even for multiple dots (so you could have something like 1.0.1 in the pkgrel).
No you cannot, makepkg is far stricter than pacman/libalpm/vercmp about most things, and in this case, as with many other packaging details, makepkg explicitly forbids this.
Allan has stated his absolute refusal to permit it: https://lists.archlinux.org/pipermail/pacman-dev/2018-June/022578.html
"I am still very much against going beyond x.y for pkgrel. In fact, I only begrudgingly accept the need for .y in there."
Ah, indeed. I'm sorry, I should've tested with makepkg. More generally, however, what would be the best approach to applying downstream/user-specific changes without breaking the versioning? The ones I know all have some issue: * Dotted pkgrel (as I suggested) breaks if the package maintainer decides to assign a dotted pkgrel themself (say the pkgrel is 1, and we change it to 1.1, 1.2, ..., but then suddenly the maintainer assigns 1.1 themself). * pkgrel "suffixes" don't work because 1foo1 < 1 (also, makepkg refuses this anyway). * The approach shown by Jonathon above also breaks (unless I've misunderstood it): 1.0 -> 1.01, but vercmp tells me that 1.01 = 1.1. Or is the answer simply: "Don't rely on package versioning for your modified packages"? Best, Tinu