On 22/10/18 5:47 pm, Tinu Weber wrote:
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
Unfortunately maybe something is needed as I use a local repository to serve my localnet. I build once and then install by update from my repository. Several times I have had to rebuild a package due to a dependency version change. In order for the other computers to recognize and download a rebuild the version has to increase somehow. Maybe an actual policy is required to control these rebuilds. For example Anjuta. This package does require a rebuild as a dependency has changed leading to a broken executable. I have had to rebuild it on my own server in order to fix it as it has not been rebuilt yet.