FS#17530 - makepkg reset pkgrel for svn/git/cvs/... package when updating pkgver
Attached to Project:
Pacman
Opened by solsTiCe (zebul666) - Wednesday, 16 December 2009, 18:47 GMT
Last edited by Allan McRae (Allan) - Wednesday, 23 December 2009, 23:29 GMT
Opened by solsTiCe (zebul666) - Wednesday, 16 December 2009, 18:47 GMT
Last edited by Allan McRae (Allan) - Wednesday, 23 December 2009, 23:29 GMT
|
Details
Summary and Info:
i was following chromium-browser-bin on AUR. and noticed the PKGBUILD was updated quite often. it is now at pkgrel=9. and found that the package i have got still have -1 pkgrel attached to their name. i found out it was makepkg that reset pkgrel to 1 when it updates pkgver. and i found this odd. because i was excepting the pkgrel to reflect the one used in the PKGBUILD. in this case pkgrel is used more like PKGBUILD revision or release than a package release wouldn't it make more sense to not reset to 1 pkgrel for svn/git/cvs/hg/... and let it what it is in the PKGBUILD when updating pkgver ? resetting pkgrel to 1 was done by commit 1e656c0a6a7f2dcf5d |
This task depends upon
Closed by Allan McRae (Allan)
Wednesday, 23 December 2009, 23:29 GMT
Reason for closing: Won't implement
Wednesday, 23 December 2009, 23:29 GMT
Reason for closing: Won't implement
Comment by Xavier (shining) -
Wednesday, 16 December 2009, 19:01 GMT
I agree that it is debatable. I am fine either way. Allan, Dan ?
Comment by Allan McRae (Allan) -
Wednesday, 16 December 2009, 19:01 GMT
The pkgrel reflects the build number for the pkgver. If the pkgver
gets updated to the latest, then the pkgrel should go to 1.
Comment by Dan McGee (toofishes) -
Wednesday, 16 December 2009, 21:44 GMT
I tend to think the way Allan does as well. If you are not sure
what PKGBUILD your local one resembles, the maintainer of the
original should probably put some sort of date or something
indicating the last revision inside the file instead of depending
on the pkgrel.