[aur-general] advice wanted on "surf" package

[Ray Kohler]

I'm the maintainer of the "surf" package in AUR, and I've discovered
an annoyance in the way I've created this package. I'd like some
advice on how to resolve it.

This package is a web browser from suckless.org, the makers of dwm. It
has very much the same coding and build style, involving a config.h
file which the user is intended to customize. Most of surf's behavior
is decided at compile-time by this file. I've modeled my package after
the "dwm" package in community, copying the default config.h into the
root of the package tarball and listing it as a local source file.
build() then copies it into the unpacked source directory before
compiling.

This is great for users of dwm who rebuild it from ABS, as it avoids
the need to modify build() in order to customize the package - the
user just needs to supply their own config.h and change the md5sum for
it.

This doesn't work so well for my surf package, though, since that's in
the AUR. Many (most?) users of AUR packages are auto-updating with
helper-tools like yaourt, pbget, and similar utilities, and it's
difficult to automatically pull updates to package materials when
you've changed one of the files. customizepkg won't help you much
either, since that can only modify the PKGBUILD, and not the config.h.

It's also annoying to me as the maintainer of the package. Anyone who
maintains a package that's meant to have the build customized, rather
than compiled as-is, will end up actually maintaining two copies - one
"stock" version to submit to AUR, and one customized version for
personal use.

Obviously, none of these issues are show-stoppers. But they are
annoying, and I don't packages I maintain to annoy my end-users. What
can I do to make this package more comfortable for the average AUR
user? Is software that expects compile-time customization just
fundamentally not very compatible with the auto-update concept?