[aur-general] VCS guidelines for svn-packages
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I know of at least two PKGBUILDs in AUR where the new makepkg puts an "M" behind the pkgver after last pacman upgrade. Is ther any advice how to handle this? Best Regards Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUpIm/AAoJEIT1NQXkgeRljMgQAOAv9385JgyHoC2GicBfkVjs ULUAp5eXpLEDyR7f7D9PptwjbcpCWrCXS4yvHN0QzfI7eexwe2t56Mc3XReyVowQ 6jn2PDMxyp1Q9Mh/e2/jP7sM2WIKh6yNARpqLAJedNUSyfbfP/GMbeQYjemtLfc0 pZphmSrauTuMfBhABasYKKkWGhFIQ3rZFIXhNkJT6AnvpaWoADFQoBDgyiZq18ry xrltWUFye524ap9awBbOyvYte0V9d9VTsFswbL3tLaAKJUwgnCjKTVQ9+j07GadM KXraf6yREQaN+faPISPBlPgYGFC713VN9pFee391fE1vO8Dda1X0ovJGugEMoUGW Djbj3ZYkzoJEEFTB9UB2uRhtdxhqc9QeTeQdU2EuyzmF53b+R50o03EwEW7xhIaV o1SiD07ur5fPoPARjIuaUsQTfIjSv/k+N9xreh3zNqMIq3E/78PDSlHHSXT4WPbG dtcpKImZV89KpSJwpCMCaxNY3d6Au3FJQrkn4dcLANNLYu4ZAgT8YiML3Y0dlSQO jGlJf+33nYjnl0/2jdN910Sm4ln2t7rT2StFxp3x+BkuGN2tG2ulCaRjIJVFIKkb bDmqGZJ+QDxCackaTqqrhYcDLknv4NTDFmQDw0Cop19+kzOkJL5/6HcVlAOLKFtb WENWxKA8UhLXmFvWr1Nx =/RlT -----END PGP SIGNATURE-----
On Thu, Jan 1, 2015 at 12:42 AM, Stefan Husmann <stefan-husmann@t-online.de> wrote:
I know of at least two PKGBUILDs in AUR where the new makepkg puts an "M" behind the pkgver after last pacman upgrade. Is ther any advice how to handle this?
How exactly are the pkgver created? Which PKGBUILDs are you talking about?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 01.01.2015 um 00:59 schrieb Karol Blazewicz:
On Thu, Jan 1, 2015 at 12:42 AM, Stefan Husmann <stefan-husmann@t-online.de> wrote:
I know of at least two PKGBUILDs in AUR where the new makepkg puts an "M" behind the pkgver after last pacman upgrade. Is ther any advice how to handle this?
How exactly are the pkgver created? Which PKGBUILDs are you talking about?
Hello, sorry for the noise. I just encountered that they both use pkgver() { cd "$srcdir/ccl" svnversion } which was a version formerly recommended in the Wiki. With pkgver() { cd "$srcdir/ccl" local ver="$(svnversion)" printf "%s" "${ver//[[:alpha:]]}" } everything is fine. Best Regards Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUpJJIAAoJEIT1NQXkgeRlBssP/RM4PMssrgtn/gFLETHkMyyr EQJ8tPB549gnrZf2WDLSStgfj9gfEd1ocN3ngC3v2TjI+M7qM5Ylvm179JuC4iYK fZ4ePLc//3F6uBY4Rb3pd+7noSVWXI9g84SQzMtxtXmSxpnN+70THwfG/jr7AxZr GhZYC001W7swHnSUwCv/ZcN8/T7d7Dsbn4T7dm+82T2nHudK1QvZmjumr+pFOtO0 7QWwZcSOLZRtpoHd0Ajt1ddN0a/9+3XQ/EejSnaiRpoW13MA34VHDjHn9PyeFlXc 8m5BKq6ubRq4aqr2gNmNmoVpiOi0g7pUOF21LMB+UhgpHbKVtJIfm/6ktmkvohjC UHAso3lwJ6eHcaPaFLpdy8fDxyulHuBuCKR8/2h9FUhu3VtZj+sQmCnzx9ZyuL0r 1S7Tl0q6LpmASMBl8Z0QN/pWJ6FmKvMxl8idAcaXbDN6JvqZwW1WZHNcDElnxcCF iwmqVQ2miGdry7f80EcrzNDLc/GSNjpo3cmdRaJjEGec93mxAsT1t4+0F9lxcWdf BYmmFJrxVrbu6m0PZatuJ7wvF3zCyfs2tmsAh08VjxI0TI1JwdbIqxzJ44tOiQGw MjMTN8Z2PrnoYKvMaRHDYhVOF0E46IdRHjiPHAuHFQM+k6A3sRIxPIu+Frqp1BWX ErzFPInlWQ45CGIoPiFL =gI4Z -----END PGP SIGNATURE-----
Hi On Wed, Dec 31, 2014 at 4:18 PM, Stefan Husmann <stefan-husmann@t-online.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 01.01.2015 um 00:59 schrieb Karol Blazewicz:
On Thu, Jan 1, 2015 at 12:42 AM, Stefan Husmann <stefan-husmann@t-online.de> wrote:
I know of at least two PKGBUILDs in AUR where the new makepkg puts an "M" behind the pkgver after last pacman upgrade. Is ther any advice how to handle this?
How exactly are the pkgver created? Which PKGBUILDs are you talking about?
Hello,
sorry for the noise. I just encountered that they both use
pkgver() { cd "$srcdir/ccl" svnversion }
which was a version formerly recommended in the Wiki.
With
pkgver() { cd "$srcdir/ccl" local ver="$(svnversion)" printf "%s" "${ver//[[:alpha:]]}"
I would like to point to importance of using revision number delimiter (by convention we use letter "r"). This delimiter allows avoid problems in case if upstream decides to make first release or uses versions with different number of components. e.g. if at revision "455" upstream decides to release version 0.1 then the revision delimiter preserves version monotonicity: 0.1.r456 > r454 without delimiter monotonicity fails: 0.1.456 < 454 This is true for other VCS as well.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 01.01.2015 um 01:34 schrieb Anatol Pomozov:
Hi
I would like to point to importance of using revision number delimiter (by convention we use letter "r"). This delimiter allows avoid problems in case if upstream decides to make first release or uses versions with different number of components.
e.g. if at revision "455" upstream decides to release version 0.1 then the revision delimiter preserves version monotonicity: 0.1.r456 > r454 without delimiter monotonicity fails: 0.1.456 < 454
This is true for other VCS as well.
Thanks, I indeed never got the point why we use this "r". Happy new year! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUpKsPAAoJEIT1NQXkgeRl9QYQANiJKR2R1EikJ9iVQkbL7Kw4 BfYKCzGVqlVLOXY0/WcXpnlJp86AoTMiMZd/0TkyLpDYIcHjeIRYVd5n68buAJH2 cq+K+MF26+PkXF75gS8le/ZOF/ZwkMoap6ZrwsvDXiYdViKA18hc3Cb7Ta+ZUq8O qKIkeQQKGO0ZgdbWYITqmoT/QX8sH+0ci2xsXAXpnX1+3ANamlRDvNFYa9UX5tnd wZhWfU/9zvWBy7Q34t0R2VedSZSAeB+dGSzRuPA1YqQBNNYiCnx4hYRA9n1n8Wkj yDut0wG8SM0sEPr4brRqQBajRU8OGiiGp0dmO7TCbuUygjBu/DG9YZ6v/kRmouo7 v7cc+1RWYgtNY3Wsa5giVKE63D6OoPlF3bWSiUoIVsHojpeHSSn49eVmPzzTErU6 A10gufwIxijKMPmggbQlgK516QZ7JBaXajHLV5KT3t8ZW0bwnhMm2483OVQhvwge vQjLxvGBjIAuJk+RFlO8/LIXcCUm6EwbMG+wDGIT6Fewodss3jMofkit1QDLwIZs Ncvc5z/VydsWt7V2s4Nvhz0cb9ZpNHUWI+Jw0ofZ7R6+TaNjTbvHheKYQS7XAgiM +cc1SMCypgqRfpCSmyXCifu6fDE0Mg8mhKz0pWyNiB8XOtXsw6kbg9Smc8nc4k5S 5PLU6lsRtfgipVk3rK+p =MeSe -----END PGP SIGNATURE-----
On Thu, 01 Jan 2015 00:42:00 +0100 Stefan Husmann <stefan-husmann@t-online.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello,
I know of at least two PKGBUILDs in AUR where the new makepkg puts an "M" behind the pkgver after last pacman upgrade. Is ther any advice how to handle this?
Best Regards Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJUpIm/AAoJEIT1NQXkgeRljMgQAOAv9385JgyHoC2GicBfkVjs ULUAp5eXpLEDyR7f7D9PptwjbcpCWrCXS4yvHN0QzfI7eexwe2t56Mc3XReyVowQ 6jn2PDMxyp1Q9Mh/e2/jP7sM2WIKh6yNARpqLAJedNUSyfbfP/GMbeQYjemtLfc0 pZphmSrauTuMfBhABasYKKkWGhFIQ3rZFIXhNkJT6AnvpaWoADFQoBDgyiZq18ry xrltWUFye524ap9awBbOyvYte0V9d9VTsFswbL3tLaAKJUwgnCjKTVQ9+j07GadM KXraf6yREQaN+faPISPBlPgYGFC713VN9pFee391fE1vO8Dda1X0ovJGugEMoUGW Djbj3ZYkzoJEEFTB9UB2uRhtdxhqc9QeTeQdU2EuyzmF53b+R50o03EwEW7xhIaV o1SiD07ur5fPoPARjIuaUsQTfIjSv/k+N9xreh3zNqMIq3E/78PDSlHHSXT4WPbG dtcpKImZV89KpSJwpCMCaxNY3d6Au3FJQrkn4dcLANNLYu4ZAgT8YiML3Y0dlSQO jGlJf+33nYjnl0/2jdN910Sm4ln2t7rT2StFxp3x+BkuGN2tG2ulCaRjIJVFIKkb bDmqGZJ+QDxCackaTqqrhYcDLknv4NTDFmQDw0Cop19+kzOkJL5/6HcVlAOLKFtb WENWxKA8UhLXmFvWr1Nx =/RlT -----END PGP SIGNATURE-----
The trailing M is added when the tracked files were modified. By the way, svnversion is terribly slow for big projects, so in some CI script I have wrote for my past employer I decided to use "svn info" and some awk instead. Bartłomiej
participants (4)
-
Anatol Pomozov
-
Bartłomiej Piotrowski
-
Karol Blazewicz
-
Stefan Husmann