Does anyone find it odd that the non-VCS PKGBUILDs explicitly check to make sure the sources have not changed and that the PKGBUILD someone uses is actually going to build the package the maintainer wrote it for, yet, VCS PKGBUILDs don't? VCS sources may change frequently, but this does not make them more secure and requiring of less scrutiny than non-VCS packages. If anything, they probably should be more scrutinized, since it would be more likely for someone to make a troublesome commit than a troublesome official release. There is also the issue that by automatically grabbing new sources without completely updating the PKGBUILD, many PKGBUILD fields may be incorrect, not just the pkgver. If the license a package is released under changes, the PKGBUILD won't care, etc.. Rather than making an often failed attempt to automatically update the pkgver and ignoring the rest of the PKGBUILD fields, why not have VCS PKGBUILDs behave more like all the other PKGBUILDs. When PKGBUILD sources change, a maintainer should have to update the PKGBUILD and PKGBUILDs which try to build using sources that don't match the PKGBUILD should fail. Figuring out the best way to check sources for all VCSs may require some creativity, but at least git would be really simple: check the hash for the last commit. Also, instead of using the date for the pkgver field of a VCS PKGBUILD, have the pkgver reflect the most recent release that the given development package is based off of. Then, use a commit field to show how many commits ahead of that release a package is. These fields would make it more clear what exactly the PKGBUILD is a PKGBUILD for. If there is no release to use commits since, the field could be left blank. This avoids ambiguity caused by different sources of a development project being released on the same day as well as issues with the sometimes significant difference between when a commit is authored and actually committed. -- David Campbell