Re: [arch-haskell] What to do now?

On Mon, 11 Oct 2010 11:19:25 +0200, Rémy Oudompheng wrote:

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.

Right that's in cabal2arch (which holds a good part of the packaging work). What I meant is that if I upload a new package today which depends on some external library then we cannot expect it to be packaged automatically. In this case it would be nice if there was a page (and/or a notification) for such packages, such that one of the team member can say that he takes care of it, which often amount to pushing a cabal2arch patch.

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.

Yes this is another nigthmare, some packages either don't give an upper bound to their dependency so they should fix their code or there dependencies. Some others clearly state an upper bound and so I see three options: * Do not package it * If the pattern is frequent enough (QuickCheck, parsec, base...), one can provide sevral versions of the same package. * Always package the different versions needed. Option 2 seems fine for now and it will push people to upgrade if they want to be packaged. Regards, -- Nicolas Pouillard http://nicolaspouillard.fr