On 10/22/18 5:47 AM, Tinu Weber wrote:
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).
I've never really seen a dotted pkgrel in the wild, except for cases like archlinux32 which use them to indicate their own rebuilds. I've happily used them since forever, for AUR packages where I rebuild them without an AUR pkgrel bump. It seems quite reasonable to me.
* 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.
To clarify the confusion here, this is not a decimal. 1.0 is no different here than in the pkgver itself -- it is 1, and a subrel of 0. 1.01 is 1, with a subrel of 01, which is just 1, and therefore identical to 1.1 1.11 would be a subrel that is two steps more significant than a subrel of 9. So Jonathon's system only works at all, due to the fact that whenever archlinux32 downgrades the pkgrel, he upgrades it again. Which isn't really working. More generally, the pkgrel system allowed by the makepkg spec doesn't acknowledge the use case of infinitely cascading derivatives.
Or is the answer simply: "Don't rely on package versioning for your modified packages"?
I'm not the best person to answer this question, since my instinctive reaction would be "okay, let's move this to [community] to make my life easier". -- Eli Schwartz Bug Wrangler and Trusted User