On Sat, Jan 17, 2015 at 12:19 PM, Ralf Mardorf ralf.mardorf@rocketmail.com wrote:
Regarding to my AUR cache [1], it seems to be common practise, that packages that moved from AUR to community get a lower "pkgrel="-value. IMO that is very annoying and doesn't make sense. I don't want to reinstall software that does work and I dislike to get tons of warnings. Why is this the common approach?
Resetting the pkgrel is indeed wrong. pkgrel should be bumped when moving to [community], and that has been my habit when moving packages from the AUR.
On 17 January 2015 at 18:23, Jan Alexander Steffens jan.steffens@gmail.com wrote:
Resetting the pkgrel is indeed wrong. pkgrel should be bumped when moving to [community], and that has been my habit when moving packages from the AUR.
I agree. Even I used to be guilty. Although this is not AFAIK documented anywhere, we were recommended to do this whenever the question came up. I have added this as an AUR guideline:
https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines&d...
-- GPG/PGP ID: C0711BF1
On Sun, 18 Jan 2015 00:40:51 +0600, Rashif Ray Rahman wrote:
On 17 January 2015 at 18:23, Jan Alexander Steffens jan.steffens@gmail.com wrote:
Resetting the pkgrel is indeed wrong. pkgrel should be bumped when moving to [community], and that has been my habit when moving packages from the AUR.
I agree. Even I used to be guilty. Although this is not AFAIK documented anywhere, we were recommended to do this whenever the question came up. I have added this as an AUR guideline:
https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines&d...
Why n+1? I prefer no change of the current dot release. The original AUR package's software was compiled, is installed and the software does work. However, n+1 wouldn't be that annoying, as a reset to .1 is, so thanks for editing the Wiki.
Regards, Ralf
Am 17.01.2015 um 20:05 schrieb Ralf Mardorf:
Why n+1?
Because it is technically another package than the one created locally. So you can easily distinguish between the last one that you complied yourself from the AUR and the first one from Community.
I prefer no change of the current dot release.
This was my first thought,too. But after thinking about it, in my oppinion n+1 ist the "right thing to do", because a community package is not only the metadata that describes how it is build (and even this has changed) but the binary package build with the arch build machines.
Uwe
On Sat, 17 Jan 2015 23:02:25 +0100, Uwe Koloska wrote:
Am 17.01.2015 um 20:05 schrieb Ralf Mardorf:
Why n+1?
Because it is technically another package than the one created locally. So you can easily distinguish between the last one that you complied yourself from the AUR and the first one from Community.
I prefer no change of the current dot release.
This was my first thought,too. But after thinking about it, in my oppinion n+1 ist the "right thing to do", because a community package is not only the metadata that describes how it is build (and even this has changed) but the binary package build with the arch build machines.
Hi Uwe,
I was thinking about this too and I've to admit that my wish is selfish :). IOW I dislike it, but I've to agree, that the increment of the package release is the correct way to go. To be honest, assumed I should have build a package that differs to the default PKGBUILD, I anyway need to compile upgrades from ABS. It's just a minor annoyance that I might have to do it for a package, I've got already installed, OTOH I seldom edit PKGBUILDs and I never edited a .install.
Hopefully everybody agrees with Rashif's paragraph. Now I'm convinced that n+1 is what should be done in the future.
Regards, Ralf
aur-general@lists.archlinux.org