[aur-general] Fwd: Re: How do I show a AUR Rebuild as a newer build?
takeya at bluewin.ch
Mon Oct 22 09:47:58 UTC 2018
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:
> "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
* 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the aur-general