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?