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

Ray Kohler ataraxia937 at gmail.com
Sun Sep 27 17:21:23 EDT 2009

On Sun, Sep 27, 2009 at 2:47 PM, Xavier <shiningxc at gmail.com> wrote:
> On Sun, Sep 27, 2009 at 8:14 PM, Ray Kohler <ataraxia937 at gmail.com> wrote:
>> 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?
> dwm was one of the very few softwares I never used a PKGBUILD for and
> don't recommend using one.
> And the problem you just described is one of the reasons.

Back on topic, I think I'll wait and see if anybody else has any
surprising suggestions that disagree with this one, and if none are
forthcoming, I'll disown the surf package. Having a pacman developer
tell me not to use pacman for a given purpose is rather convincing, in
which case, I should let someone who _isn't_ convinced take on the
package and worry about the problem, instead of me. ;)

More information about the aur-general mailing list