[aur-general] When should pkgrel be updated?
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.
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
Am Fri, 1 Apr 2011 08:12:42 +0800 schrieb Oon-Ee Ng <ngoonee.talk@gmail.com>:
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.
In both cases pkgrel needs to be incremented. In the first case a package was changed which probably had an influence of the resulting package. So people need to update this package to get these changes. If there's a bug in the package this bug should, of course, be fixed. To let the user know about this fix and let the users install the fixed package it's, of course, also necessary to increment pkgrel. In the second case there have been made changes to commands and depends. Both can also have influence of the resulting package. If a dependency is added it's, of course, necessary that people install these dependencies, too. If a dependency is removed people should also be notified about this. This could e.g. happen if a dependency was renamed in or removed from the repos, two libraries have been merged, etc. A changed command usually has also an influence on the resulting package. Pkgrel shouldn't be incremented only if an unimportant part was changed like changing pkgdesc, removing or adding a comment, etc. If something is changed which results or can result in a modified package the pkgrel should be incremented. Heiko
On 1 April 2011 08:12, Oon-Ee Ng <ngoonee.talk@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 change and 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 If in doubt about more scenarios, please describe them. -- GPG/PGP ID: 8AADBB10
On Fri, Apr 1, 2011 at 4:12 AM, Ray Rashif <schiv@archlinux.org> wrote:
On 1 April 2011 08:12, Oon-Ee Ng <ngoonee.talk@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: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
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@archlinux.org> wrote:
On 1 April 2011 08:12, Oon-Ee Ng <ngoonee.talk@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
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@archlinux.org> wrote:
On 1 April 2011 08:12, Oon-Ee Ng <ngoonee.talk@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
On Fri, Apr 1, 2011 at 9:39 AM, Dave Reisner <d@falconindy.com> 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@archlinux.org> wrote:
On 1 April 2011 08:12, Oon-Ee Ng <ngoonee.talk@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
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.
On 1 April 2011 23:48, Thomas S Hatch <thatch45@gmail.com> wrote:
On Fri, Apr 1, 2011 at 9:39 AM, Dave Reisner <d@falconindy.com> 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@archlinux.org> wrote:
On 1 April 2011 08:12, Oon-Ee Ng <ngoonee.talk@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
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
participants (7)
-
Dave Reisner
-
Denis A. Altoé Falqueto
-
Heiko Baums
-
Jelle van der Waa
-
Oon-Ee Ng
-
Ray Rashif
-
Thomas S Hatch