[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...

http://pkgbuild.com/git/aur.git/

https://github.com/falconindy/bin-scripts/blob/master/aurdiff

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.

dave



More information about the aur-general mailing list