[aur-general] When should pkgrel be updated?

[Ray Rashif]

On 1 April 2011 23:48, Thomas S Hatch <thatch45 at gmail.com> wrote:
> 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.

Changing makedeps that affect the resulting binary is considered
changing deps. So that's different, and you must bump.

The bottomline is that if only the build scripting changes, but not
the package itself, there is no need to bump. If you want to make your
changes show up in ABS, just release the buildscripts. Otherwise, you
can tell users to checkout from svn.

It's the same for AUR users. If a build breaks, just update your
PKGBUILD without a pkgrel bump. Old users will keep on running the
software undisturbed, new users will get the new PKGBUILD. A broken
build does not affect those who already have the package installed.


--
GPG/PGP ID: 8AADBB10