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.
