On Sun, Apr 18, 2010 at 5:39 AM, David Campbell <davekong@archlinux.us> wrote:

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

A quick answer to say these are all good points imo. However, the "automatic bump" is also a good feature to have. We should have both and just decide for a default. When makepkg started to bump automatically the version, some people quickly reclaimed the need to hold the version, and that option was introduced : --holdver Prevent automatic version bumping for development PKGBUILDs However this only works for cvs , which sets pkgver to a date and can checkout a date, and svn which sets pkgver to a revision and can checkout a revision. The support for all VCS other than cvs and svn is desperately dumb. The second biggest difference between cvs/svn and the rest, that accounts for a lot of suckage with the other VCS, is the inability to query remotely the latest revision/version. We need to download/pull the code first.