[aur-general] When should pkgrel be updated?

Dave Reisner d at falconindy.com
Thu Mar 31 20:21:28 EDT 2011

On Fri, Apr 01, 2011 at 08:12:42AM +0800, Oon-Ee Ng wrote:
> I've seen (in the past) various packages on the AUR which jumped by 3
> or 4 pkgrels in a very short period of time. Sometimes it happens like
> this:-
> 1. Maintainer changes something and breaks the package with pkgrel=2
> 2. Bug reported on comments. Maintainer reverts change and makes pkgrel=3
> It can also happen like this:-
> 1. Maintainer makes changes to pkgdesc or cleans up some of the
> commands, depends, etc. sets pkgrel=2
> For both of the cases above, is pkgrel updating really necessary? For
> the second one, I think not, as changing documentation doesn't
> (shouldn't) require recompilation of the package by its users.
> Similarly if depends changes, users who already have the package
> installed would already have the dep, so no reason for such users to
> upgrade?
> For the first case its a bit more tricky. My reasoning is that if the
> PKGBUILD breaks and can't be built at all, the maintainer could simply
> release with the same pkgrel. Noone would have been able to build
> pkgrel=2 in that example anyway, so why jump to pkgrel=3?
> The reason I bring this up is because there's no easy way (yet) to
> diff what's changed between versions of the package, and hence when I
> notice a pkgrel change I can't really check to see what has been
> changed and whether its worth recompiling the package (for larger
> packages like firefox4 this can be significant).
> Comments appreciated.

Two ways to diff PKGBUILDs, actually...



The latter requires that you keep your own cache of PKGBUILDs, but for
some people, this is standard fare.

wrt pkgrels, if there's a change and its not a version bump, I would
change the pkgrel. If the pkgrel is constantly being bumped because of
human error, that's a maintainer problem and nothing else.


More information about the aur-general mailing list