Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#13820 - makepkg is unnecessarily managing svn revisions
Attached to Project:
Arch Linux
Opened by paul (pwt) - Monday, 16 March 2009, 15:42 GMT
Last edited by Allan McRae (Allan) - Monday, 16 March 2009, 22:07 GMT
Opened by paul (pwt) - Monday, 16 March 2009, 15:42 GMT
Last edited by Allan McRae (Allan) - Monday, 16 March 2009, 22:07 GMT
|
DetailsDescription:
Currently, makepkg performs unnecessary tasks which are nowhere documented (e.g. wiki, manpage, ...): If the PKGBUILD contains the variables _svntrunk and _svnmod it looks for the latest svn revision of the code and REPLACES pkgver with what it gets. This is wrong IMO for at least two reasons: 1. It is useful to be able to extract a svn tree at a specific revision number, regardless of further upstream updates (which may break things more than fix them). always fetching the last update is wrong. Having makepkg force and not respect the intention of the package builder is wrong. 2. It is my understanding that user variables in PKGBUILDS are prefixed by "_". So should be considered both _svntrunk and _svnmod. If makepkg makes an explicit usage of them, it should use other names. So my feature request is simply to remove this "functionality" from makepkg. To stick with the KISS mantra, the user should determine by himself the last revision number if he wishes so. And makepkg should not interfere otherwise. Additional info: * package version(s) pacman 3.2.2-1 * config and/or log files etc. N/A Steps to reproduce: N/A |
This task depends upon
Please close this request. I will use the --holdver switch.