On Fri, 2011-04-01 at 12:21 -0300, Denis A. Altoé Falqueto wrote: > On Fri, Apr 1, 2011 at 4:12 AM, Ray Rashif <[email protected]> wrote: > > On 1 April 2011 08:12, Oon-Ee Ng <[email protected]> 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 changand makes pkgrel=3 > > > > It's really very simple - you only need to remember this: > > > > Whenever the resulting binary changes (in an important way) for the > > user, you bump pkgrel. > > > > Examples: > > > > * Changing pkgdesc -> do NOT bump (unless it's severely wrong or something) > > > > * Changing deps -> bump > > > > * Changing makedeps -> do NOT bump, ever > > > > * Changing optdeps -> do NOT bump (unless very important functionality > > provided) > > > > * Changing build stuff (i.e changing PKGBUILD but no change to > > resulting binary) -> do NOT bump > > Are you sure about that? I would bump pkgrel in all your examples, > except the first. Even though they may not change the resulting > binary, they change how they are built. I always thought of pkgrel as > a way to differentiate between versions of PKGBUILDs. >
a Makedep isn't that important so i wouldn't bump there, just like the build stuff. And if someone used ABS the makedep fix would be already there in svn ;) -- Jelle van der Waa
