[aur-general] When should pkgrel be updated?

Thomas S Hatch thatch45 at gmail.com
Fri Apr 1 11:48:42 EDT 2011


On Fri, Apr 1, 2011 at 9:39 AM, Dave Reisner <d at falconindy.com> wrote:

> On Fri, Apr 01, 2011 at 05:31:34PM +0200, Jelle van der Waa wrote:
> > 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 <schiv at archlinux.org>
> wrote:
> > > > On 1 April 2011 08:12, Oon-Ee Ng <ngoonee.talk at gmail.com> 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
> >
>
> A change in makedeps might fix a broken build, or it might enable a new
> feature that's conditionally linked in based on the presence of the dep.
> Definitely seems worthy of a pkgrel bump.
>
> dave
>
>
When packaging it is critical to ensure that the resulting package is
consistent regardless of the build environment, this means the build can
change based on what deps are installed, for instance I have seen many
PKGBUILDS create different packages because software to facilitate language
bindings were not present.
This would mean that the makedeps need to fulfill the configuration of the
package source, and adding/changing makedeps can have direct influence on
the resulting binary.

I would recommend that the only time one should not bump the pkgrel is if
the changes are menial and completely contained in the PKGBUILD, and that if
the packager is unsure, bump the pkgrel.


More information about the aur-general mailing list