Arch Linux User Repository

@trya Regarding local:// vs. hib//, I think it's possible to specify alternatives like so: source=("$_gamepkg::hib://$_gamepkg" "$_gamepkg::local://$_gamepkg" ...) But I haven't tested it. If it works (i.e. first try the hib dlagent if any, if it fails use local), that would be the ideal solution imo.

@trya You don't have to wait for a new maintainer to volunteer, before disowning a package. Simply disown as soon as you're not interested in the package anymore, or as soon as you know you're not gonna put in the work to maintain/improve it anymore. Then new maintainers can just pick them up (otherwise they wouldn't even know that it's available)... (For what it's worth, I'd be willing to maintain World of Goo and Braid myself, I love both games and still play them from time to time.)

@C5OK5Y: I'm still not too keen on doing it, because World of Goo is not specifically distributed through the HIB. Nevertheless, I'd gladly let you maintain the PKGBUILD if you want to (Braid in the same case, I'd like to disown all my PKGBUILDs of commercial games).

@trya: Have you considered using the hib::// DLAGENT instead of local://? It greatly simplifies fetching of HB source files. Examples of configuring the hib::// DLAGENT from the user side are described here[1] quite thoroughly. [1] https://aur.archlinux.org/packages/ps/psychonauts/PKGBUILD

@Kyrias: why would you need a 32-bit library for a game which has a 64-bit executable?

Should add that you need lib32-sdl_mixer from AUR if you're on 64-bit to post_install()

I must admit the error message from makepkg can be very misleading because the PKGBUILD contains a unusual download agent. I didn't remember I could mess with pacman and makepkg variables from the PKGBUILD, so what I'll do for this sort of package is to add a "local" download agent directly into the PKGBUILD. Now, makepkg should behave as expected and issue a "NOT FOUND" error if the user doesn't provide the local sources. PKGBUILD updated.

@trya, thx!

@trya: I've handled this in my newly created own PKGBUILDs, by putting that logic into a separate Bash function. This way build() stays clean, and the functionality can easily be copied from one PKGBUILD to another. (See e.g. https://aur.archlinux.org/packages.php?ID=61969) However, I would much prefer if makepkg could natively handle this using a special SOURCE protocol like you use. Although I would call it local:// rather than file://, to make it clear that it does *not* specify an arbitrary filesystem path, but rather is a generic way for the PKGBUILD to say "I need this file provided locally by the user". How the user provides it, should not be any of the PKGBUILD's concern - it would be an implementation detail of makepkg or the AUR helper. Makepkg / the AUR helper could give the user the choice to either manually copy the file into the PKGBUILD dir, or set a $LOCAL_PACKAGE_SOURCES environment variable (like I implemented in my above mentioned Bash function), or even interactively query the user for the file. Then every user can choose how they want to provide such files, while PKGBUILD authors would not need to care about any of this.

@smls: it's a workaround after all. I found it elegant at the time because, compared to the previous version of the PKGBUILD, it permitted me to greatly simplify the build() function. I don't know if there's a token for makepkg in order to exclude a file from the source tarball, I ought to find if it's possible and make a request eventually. The old PKGBUILD: http://sprunge.us/iMdY