On Mon, Oct 22, 2018 at 07:27:21 -0400, Eli Schwartz via aur-general wrote:
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.
There was lib32-fontconfig at one point [1], so adding a .1 or .2 to that pkgrel wouldn't have worked with makepkg.
[…] More generally, the pkgrel system allowed by the makepkg spec doesn't acknowledge the use case of infinitely cascading derivatives.
That makes me sad, but I'll accept that as an anwer. How about pacman/libalpm/vercmp? Can I rely on them treating multiply dotted pkgrels as expected, or have I entered "expect your stuff to break one day" territory?
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".
Heh. I guess for the mortals among us, the best/cleanest way is to bump the pkgVER (as pointed out by LoneVVolf [2]), and stop attributing any sort of semantic meaning (upstream/downstream) to the pkgrel? Best, Tinu [1] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/lib32-fontconfig&id=b225dccc1f415ceb05c3ec85ff100eb556603613 [2] https://lists.archlinux.org/pipermail/aur-general/2018-October/034385.html