[arch-haskell] Road to binary repository
Peter Simons
simons at cryp.to
Sat Oct 23 13:30:17 EDT 2010
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
More information about the arch-haskell
mailing list