[arch-general] Pointless to use non-md5 for makepkg INTEGRITY_CHECK

[Aaron Schaefer]

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