On Fri, Apr 1, 2011 at 4:12 AM, Ray Rashif wrote:

On 1 April 2011 08:12, 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 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: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

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 wrote:

...

On 1 April 2011 08:12, 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 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

On 1 April 2011 23:48, Thomas S Hatch wrote:

On Fri, Apr 1, 2011 at 9:39 AM, Dave Reisner 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 wrote:

...

On 1 April 2011 08:12, 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

...

...

...

...

this:-

1. Maintainer changes something and breaks the package with pkgrel=2 2. Bug reported on comments. Maintainer reverts changand makes

On Fri, Apr 01, 2011 at 05:31:34PM +0200, Jelle van der Waa wrote: like 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