At the request of the upstream developer, I was attempting to change the md5sums in my tarsnap PKGBUILD (http://aur.archlinux.org/packages.php?ID=22963) to use sha256 instead, and ran across a couple of issues. The way makepkg works, when you set INTEGRITY_CHECK in makepkg.conf, those values effect BOTH the generation of the checksums and also the verification upon package compilation. I believe the variable should only effect checksum generation. Validation of the checksums upon compilation should only fail in two cases: 1) There are no checksums listed in the PKGBUILD or 2) One of the listed checksums does not validate against the source The way things are now, it's not feasible to use a non-standard (read non-md5) checksum, because everyone who would like to build the package themselves would either have to alter their own makepkg.conf file, or simply ignore the warning of verification failure. Unless everyone moved to a different standard of checksum at the same time, I don't think it would be realistic for us to expect people to do this. I can't think of a use case where it wouldn't make sense just to verify whatever checksums are listed in the PKGBUILD, and only consult the INTEGRITY_CHECK settings when generating new checksums. This process also led the the discovery of an issue with the AUR code...it seems as though the AUR is hard-coded to check for md5sums only, so if you attempt to upload a package with just a sha256sums line, it will complain and prohibit you from updating the PKGBUILD. Has anyone else ever tried to use a non-standard INTEGRITY_CHECK setting? Is there something here that I'm missing? -- Aaron "ElasticDog" Schaefer