[pacman-dev] VCS-PKGBUILDs

David Campbell davekong at archlinux.us
Sat Apr 17 23:39:12 EDT 2010

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

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
David Campbell

More information about the pacman-dev mailing list