Hi Rémy,
It is necessary to increment $pkgrel in order to get pacman to know an update is available (if the goal is a binary repo).
you are right. If package A depends on B, and B is updated, then we need to bump $pkgrel in A (and re-build it) to keep the binary repository consistent. Now that I think of it, the same policy is required for maintaining AUR as well! Your build system is clearly more mature than the Makefile I cooked up, so IMHO it's best to forward with the toolchain you have developed. I like about your solution that it re-uses the existing Arch devtools, and the chroot-builds are also very nice to have. Would it be possible to move development from your archhaskell-build repository into one that's accessible to all members of the organization? I have a few minor patches to make the scripts work on my i686-only machine. The way I see it now, our "job" is maintain the PKGLIST file. That file provides a mapping from Cabal to ArchLinux. For every package, we know - Cabal package name, - Cabal package version, - ArchHaskell package name, and - ArchHaskell package release number. Using that file, an automated process can build the entire repository to guarantee consistency and to provide binary packages. Very nice! There is one more thing that I'd like to suggest. Oftentimes, I'd like to pass certain flags to Cabal packages during the configure phase. It should be possible to build Pandoc, for example, with -fciteproc. This kind of choice influences the dependencies that are required to build the package, so cabal2arch would have to know about that choice when the PKGBUILD is generated. Would it be possible implement that feature in our build system? Could we augment our PKGLIST with a set of "extra flags" for every package? Take care, Peter