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
