[aur-general] Fwd: Re: How do I show a AUR Rebuild as a newer build?
Tinu Weber
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:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181022/a28b487e/attachment.asc>
More information about the aur-general
mailing list