In all honesty I think the issue is that archlinux AUR packages are being generated in a very naive way (and not a Archlinux philosophy in general). The whole point of AUR is that its supposed to make it very easy for people to upload packages/libraries.

In my opinion putting such packages in AUR in the first place (apart from the 'required' and 'basic' packages) was a mistake in the first place. I had numerous issues with AUR haskell libraries before (because those packages being in AUR kind of gives the impression they are supposed to be used over cabal)

The thing is, libraries at least should be automated. There are just way too many packages in Hackage for someone to go through and manually check if something goes wrong, and you get the issues described previously in conflicts of latest version and outdated versions of libraries installed through AUR/cabal (and in my case having to manually go through and use cabal2arch to fix things was taking up way too much time). C/C++ libraries can be checked by hand because there aren't many of them (as mentioned earlier) where as the 'Haskell' way of doing things is using lots of smaller modularized libraries.

If people just wanted an auto udpate version of cabal that works through arch's package management, then there should have just been a pacman wrapper which when you install/update haskell libraries/packages, it creates a local package through cabal2arch instead of using AUR.

You either have everything properly updated (assuming it doesn't fail building for w/e reason) or if you want to 'clone' cabal onto AUR, then only do it for the necessary/base/required packages which is easy to keep track of

On Wed, Aug 25, 2010 at 3:01 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 25 August 2010 14:56, Mathew de Detrich <deteego@gmail.com> wrote:
> Thanks for clearing the stuff up. The issue is Ivan, that the archlinux aur
> packages are auto generated (even the "official ones"). The only packages
> that I believe were ever done by hand was gt2hs (old gtk version) and since
> its changed to gtk that isn't the case anymore

Which I've argued with Don about before.  Automation is good, but you
should then double-check what it spits out.

(Note also that in Gentoo, we abstract away the actual interaction
with Cabal so for simple libraries we just have to specify things like
dependencies, download location, etc.).

> If there is some issue (like you explained with the --flag=-have-gio flag)
> archlinux aur would have the same problem. To make things more clear, here
> is an example of the pkgbuild for gtk (from AUR)
> http://aur.archlinux.org/packages/haskell-gtk/haskell-gtk/PKGBUILD
> As you can see, all the script does is invoke runhaskell
> configure/build/haddock etc etc and then registers it with GHC. Thats the
> exact same with every other AUR package, and it isn't any different from
> doing a cabal install (which invokes configure/build/haddock anyways). That
> pkgbuild generates the actual package you install through pacman, only
> difference being the library is already built (but it still registers
> through GHC). Likewise the uninstalling is the same story

Yup: I think Don's approach of "oh, if we want to change something
we'll just re-generate them all" rather short-minded (then again, that
seems to be the whole point of Arch, one reason why if I give up
Gentoo I'm more likely to go to Fedora than Arch).

> So the issues you stated would also be the case with AUR, which means I am
> not worse off using cabal-install

Except if you help out with AUR, you can try to make these things better... ;-)

And that uninstallation with AUR should be easier/better than what
cabal-install can do, and the ability to specify non-Haskell deps.

--
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com