Excerpts from Andrew Coppin's message of Sun Sep 21 02:44:10 -0500 2008:
1. How is putting something into a Cabal package different from just handing somebody the source code and telling them to run ghc --make?
Cabal can handle things for you like when your package depends on external data files; when cabal compiles the code it autogenerates a module which you import that will give you the path name to where-ever it is installed, which is nifty in case you for example are uploading a language for an interpreter and want to store the languages' prelude somewhere. It also allows for more tight constraints on dependent package versions i.e. with it you can specify the exact package and version you need to build (for example, parsec < 2.1 && > 3.0 which a few packages do.) With --make you would have to include a lot of -hide-package flags and a lot of other things, too. It is also naturally the easiest way to actually install libraries since it will register that library with ghc-pkg for you.
2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
Having these packages available as native packages for a package manager lets you distribute applications easier for example; if someone just wants to install <appname> from say, the archlinux user repository (which is source-based, mind you - the official repo is binary based,) it may also depend on parsec, haskell98, HTTP, etc.. Having these packages available natively to the manager means it can track the dependencies and install the application by itself - this is useful for example if someone just wants to use a haskell application but they don't code haskell (example: darcs or pandoc.) Of course, if you are doing haskell development, the best possible way to go (IMO) full-blown cabal install since you will always get the most up-to-date code - plus mixing and matching native package managers and e.g. cabal install doesn't really work well IME; for example if you want to install alex from macports, it will automatically install ghc too, even if you actually have it installed, but you didn't install it through macports (I just used the .dmg file that Manual Chak. made.) Likewise you may want to get something and it might depend on the HTTP library - it could very well already be installed via cabal-install, but the native manager won't dig into GHC to find out and will instead just work based on what it knows is installed in its package database. Austin