On 2010/10/11, Nicolas Pouillard wrote:

On Sun, 10 Oct 2010 17:55:47 +0100, Magnus Therning wrote:

...

The set of packages currently on AUR is *huge*, I think Don recently mentioned something in the order of 2000 haskell packages on AUR, and that is about 10% of AUR.  I would suggest starting somewhat smaller than that :-)

...

Maybe starting from Haskell Platform and growing on demand from that?

Sure we should take care that the Haskell Platform works nicely. Basically the hard ones are those depending on external libraries, we have to manually take care of them. Then packages only made of pure Haskell code on top of that should be automatically built. Maybe one can start with recent uploads to Hackage and transitively build/package their dependencies.

cabal2arch is supposed to handle that automatically. Problems are either an upstream problem or a bug in cabal2arch :) For example, cabal2arch gives me a haskell-pango PKGBUILD depending on pangocairo, which is wrong, for some unknown reason because it should be translated to pango. Another example is haskell-openal which does not have the obvious dependency on openal, but that dependency is not stated anywhere in the cabal file. My automated build is still running happily, with 633 packages built. There is still a dependency nightmare due to packages needing old versions to run. -- Rémy.

remyoudompheng:

On 2010/10/11, Nicolas Pouillard wrote:

...

On Sun, 10 Oct 2010 17:55:47 +0100, Magnus Therning wrote:

...

The set of packages currently on AUR is *huge*, I think Don recently mentioned something in the order of 2000 haskell packages on AUR, and that is about 10% of AUR.  I would suggest starting somewhat smaller than that :-)

...

Maybe starting from Haskell Platform and growing on demand from that?

Sure we should take care that the Haskell Platform works nicely. Basically the hard ones are those depending on external libraries, we have to manually take care of them. Then packages only made of pure Haskell code on top of that should be automatically built. Maybe one can start with recent uploads to Hackage and transitively build/package their dependencies.

cabal2arch is supposed to handle that automatically. Problems are either an upstream problem or a bug in cabal2arch :) For example, cabal2arch gives me a haskell-pango PKGBUILD depending on pangocairo, which is wrong, for some unknown reason because it should be translated to pango. Another example is haskell-openal which does not have the obvious dependency on openal, but that dependency is not stated anywhere in the cabal file.

There's a table (wired in) to cabal2arch, that gives the necessary translations between C libraries that appear in Cabal files (e.g. "pangocairo") and the actual C library name on Arch (e.g. "pango"). This list should be an external, shared file (its not currently). The main job of the cabal2arch maintainer is to keep adding translations to this list. http://haskell.org/haskellwiki/Arch_Linux/Arch_Haskell_Group_Maintainership#...