[aur-general] pkgrel - Is it correct that some "fixes" aren't "fixes"?
Hi, see https://aur.archlinux.org/packages/dh-make/ for "The fix of the source url was neither a fix...". Is it correct that some "fixes" aren't considered as being "fixes", so that the pkgrel shouldn't increase? Regards, Ralf
On 06/22/2018 07:18 PM, Ralf Mardorf wrote:
see https://aur.archlinux.org/packages/dh-make/ for "The fix of the source url was neither a fix...".
Changing the source url to a different url of the same source will not influence the built package
Is it correct that some "fixes" aren't considered as being "fixes", so that the pkgrel shouldn't increase?
If the built package does not change, pkgrel does not need to be incremented. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Fri, 22 Jun 2018 19:20:24 +0200, Robin Broda via aur-general wrote:
On 06/22/2018 07:18 PM, Ralf Mardorf wrote:
see https://aur.archlinux.org/packages/dh-make/ for "The fix of the source url was neither a fix...".
Changing the source url to a different url of the same source will not influence the built package
Is it correct that some "fixes" aren't considered as being "fixes", so that the pkgrel shouldn't increase?
If the built package does not change, pkgrel does not need to be incremented.
Moving a package from AUR to Community or vice versa also doesn't change the content. I guess the pkgrel should inform about each change done to a package providing the same pkgver. Somebody might have experienced that 2.201801-1 didn't build. The user is monitoring the package and expects that the fixed version is > 2.201801-1, so assuming the pkgver should be the same, it should be 2.201801-1+. If the pkgrel isn't increased, how should the user notice that the issue is fixed, by monitoring each change to the URL? Keep in mind, if the content of the URL does change, it just could be an additional comment, it not necessarily is a fix. The broken package already was released, so fixing it IMO is a fix worth increasing the pkgrel.
On Fri, 22 Jun 2018 19:33:05 +0200
Ralf Mardorf
Moving a package from AUR to Community or vice versa also doesn't change the content. I guess the pkgrel should inform about each change done to a package providing the same pkgver.
You're confusing package with PKGBUILD. Changes to the package do require bumping the pkgrel, changes to the PKGBUILD do not.
On 06/22/2018 07:33 PM, Ralf Mardorf wrote:
On Fri, 22 Jun 2018 19:20:24 +0200, Robin Broda via aur-general wrote:
If the built package does not change, pkgrel does not need to be incremented.
Moving a package from AUR to Community or vice versa also doesn't change the content. I guess the pkgrel should inform about each change done to a package providing the same pkgver.
Moving a package from the AUR to [community] means that [community] now holds a build made by the adopting TU, incrementing the pkgrel ensures that package users automatically get the now-official build. Unless the package is 100% reproducible and was built in a clean environment, the package contents will differ to the ones that users who built it themself may already have -> My initial statement - the built package has changed.
The broken package already was released, so fixing it IMO is a fix worth increasing the pkgrel.
Nobody could've possibly built it like that, so the package never existed in that state. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 06/22/2018 01:33 PM, Ralf Mardorf wrote:
Moving a package from AUR to Community or vice versa also doesn't change the content. I guess the pkgrel should inform about each change done to a package providing the same pkgver.
That's a change to the built package, which merits a pkgrel. Not a change to the PKGBUILD, which does not merit one.
Somebody might have experienced that 2.201801-1 didn't build. The user is monitoring the package and expects that the fixed version is > 2.201801-1, so assuming the pkgver should be the same, it should be 2.201801-1+.
Anyone is more than free to expect whatever they want, but if they literally have zero grounds for expecting it, then their expectations are completely untethered from reality and they should additionally expect, that they will often be wrong.
If the pkgrel isn't increased, how should the user notice that the issue is fixed, by monitoring each change to the URL? Keep in mind, if the content of the URL does change, it just could be an additional comment, it not necessarily is a fix.
Are you seriously worried that maintainer will add comments but leave the PKGBUILD broken? And how about this, what if the PKGBUILD "fixed" itself by having upstream sources become available, that used to not be available? How will any sort of monitoring detect that? It's not a problem. PKGBUILDs are not written for the explicit sake of some weird monitoring program. Try to build it, see if it works, if yes, good, if not, complain on the details page. We're not going to replace human interaction with pkgrel bumps -- it is both technologically and socially wrong. -- Eli Schwartz Bug Wrangler and Trusted User
participants (4)
-
Doug Newgard
-
Eli Schwartz
-
Ralf Mardorf
-
Robin Broda