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
signature.asc
Description: PGP signature