[arch-haskell] What to do now?

[Nicolas Pouillard]

On Mon, 11 Oct 2010 11:19:25 +0200, Rémy Oudompheng <remyoudompheng at gmail.com> wrote:
> On 2010/10/11, Nicolas Pouillard <nicolas.pouillard at gmail.com> wrote:
> > On Sun, 10 Oct 2010 17:55:47 +0100, Magnus Therning <magnus at therning.org> 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