[aur-general] Fwd: Re: How do I show a AUR Rebuild as a newer build?

[Tinu Weber]

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
-------------- 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/855bf442/attachment.asc>