2011/3/28 Mathew de Detrich
Of course, trying to force archlinux package management to have the same granularity as arch's is out of the question, which I guess made me come with my second idea. Wouldn't it just be smarter to have the archlinux haskell environment set up like this. Archlinux's package management is one that makes some sacrifices (in regards to having a rolling release system thats always up to date at the cost of granularity in certain areas) - ghc is an official package in the official repository - haskell-platform will be the same as it is currently (uses GHC, and cabal2arch packages from both the official repository and AUR). This is fine since the point of haskell-platform is the standard packages it uses are frozen for half a year. So the only haskell libraries on AUR would be the ones in haskell-platform (and arguably these should be in the official repository, as well as the base haskell-platform package) - All other libraries users would just install/update with cabal install and not through AUR/cabal2arch/bauerbill etc etc. - Haskell packages that provide binaries would check for their dependencies using cabal/ghc-pkg, ...
I don't really understand what you mean. Nothing prevents you from using cabal to install packages. The point of the binary repositories is to speed up the task by providing a set of pre-compiled packages for common libraries. We do not intend to replace cabal as a package management system, since obviously Archlinux package system is not strong enough to express the full meaning the cabal dependencies. My piont of view on this is - archlinux provides GHC, haskell-platform (minus the OpenGL packages), darcs and xmonad, + dependencies of common programs - arch-haskell provides a suitably chosen version of several additional libraries as binary packages or PKGBUILDs on AUR, and having more libraries can't be a bad thing - other packages (older versions of packages, etc.), that are problematic for package management are really meant to be installed through cabal. And this is basically what you describe. And actually people can use any tool they prefer to manage packages. If an older version of a package (e.g. parsec 2) happens to be very common and very needed, it is perfectly possible to provide a binary package or a PKGBUILD for it with the correct "provides" fields so that it can be used in a transparent manner by PKGBUILDs that need it. All we have to do is to find a correct balance between no binary package and too many binary packages. The current situation looks good. Rémy.