On Tue, Mar 29, 2011 at 9:15 AM, Leif Warner <abimelech@gmail.com> wrote:

I think by "binary" you mean the executables installed by a Haskell package (under /usr/bin), as opposed to libraries (under /usr/lib)? Just a little confusing, as I'm only used to calling the pre-compiled packages (.pkg.tar.xz files) that. Those are only on the standard arch linux repos (core, extra, community), and our haskell one. AUR and HABS have no binaries, just PKGBUILD scripts.

Yes, I am specifically talking about about "programs" that are coded in haskell (currently the only well used one happens to be xmonad). For example its currently not possible to install the leksah (a haskell IDE) package in AUR for reasons I stated earlier If you use cabal install for packages currently, then it can have conflicts if you try to install a haskell program (that would go under /usr/bin) that depends on libraries that you have already installed with cabal install, and if there is dependency mismatching in those areas then things get nasty

If you use yaourt to install Haskell packages from AUR, it should pull in any needed dependencies that exist as Arch packages. Haskell packages that are only an executable should have no run-time dependencies (no Haskell ones anyway), so you're free to uninstall any Haskell packages that were built as dependencies. If you're using the arch-haskell binary repo, it won't install any build-time dependencies, anyways. If there's programs that need dependencies in versions not provided by arch-haskell, we could try to fix it, but you might just have to cabal-install it.

The issue as I described earlier is when you have a package like yesod (which depends on a whole number of other packages), and one of the packages that yesod depends on is updated. If you do a yaourt -Syu in this situation, then that package can't update (because GHC complains it will break the system, which was an issue I described months ago on another mailing list thread). To get around this, the cabal package is done with a forced install, however that breaks GHC

You can of course, only use cabal-install for all your Haskell packages, and only use Arch packages for providing e.g. Haskell Platform, if you don't wish to manage your Haskell packages as Arch packages. I go this route with Ruby gems.

-Leif Warner

On Mon, Mar 28, 2011 at 2:49 PM, Mathew de Detrich <deteego@gmail.com>wrote:

...

Well basically the point would be that libraries would be installed through cabal install however haskell binaries you would install through AUR, and the PKGBUILD would (indirectly through some shell script) check for dependencies, and if a library isn't installed it would temporarily install it in /tmp where the PKGBUILD would link it with ghc to build the binary.

Obviously as mentioned earlier, it's not really an isssue now, but when more widely used haskell binaries are on AUR, if people installed packages thorough cabal and not AUR, something along these lines will need to be done On 29 Mar 2011 05:07, "Rémy Oudompheng" <remyoudompheng@gmail.com> wrote:

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

On Tue, Mar 29, 2011 at 9:39 AM, Rémy Oudompheng <remyoudompheng@gmail.com>wrote:

On 2011/3/28 Mathew de Detrich <deteego@gmail.com> wrote:

...

Well basically the point would be that libraries would be installed through cabal install however haskell binaries you would install through AUR, and the PKGBUILD would (indirectly through some shell script) check for dependencies, and if a library isn't installed it would temporarily install it in /tmp where the PKGBUILD would link it with ghc to build the binary.

This is usually called "building packages in a clean chroot" and is a non-issue here.

I am specifically talking about doing dependency tracking of haskell binaries (or programs, whatever name you want to give them) through cabal and not through archlinux's package system (which it is currently done with the PKGBUILD depends)

...

Obviously as mentioned earlier, it's not really an isssue now, but when more widely used haskell binaries are on AUR, if people installed packages thorough cabal and not AUR, something along these lines will need to be done

You don't make your point clear enough. You don't seem to want anything particular to be done. You want things to be undone. Since everything you ask for (GHC, haskell-platform) seems to be already there.

I guess I didn't communicate what I was trying to say clearly enough Originally I tried to set up the haskell environment in the way that was "expected" for an arch system, that is to use AUR packages for the libraries (and if the packages aren't available on AUR you notify the mailing list, and you can use tools like cabal2arch/bauerbill in the meantime) This however caused a number of issues once you deal with haskell installations that are non trivial, as I have described in this mailing list among the earlier one. These issues include - AUR doesn't always have fully updated versions of the hackagedb package - archlinux package management (through AUR) doesn't support the same granularity as cabal install, so using the archlinux-aur package management as an overlay above cabal install causes these types of problems. These include things like having to install an older version of package X without having to completely uninstall X (and its dependencies) to install that older version of X in order to build some haskell library/binary - Breaks between haskell-platform releases are more painful then they should be, due to the reliance on the cabal2arch tool What I am trying to say is that this suggested archlinux environment (for haskell) is very painful for the non trivial stuff (like if you rely on packages that aren't completely maintained, or a package that depends on another package with specific version ranges etc etc) and its *far* easier to just use cabal install for libraries. Of course for this *nothing* needs to be changed, except for the issue with non production haskell binaries/programs (which should be installed through AUR or even in official repositories). If we look at leksah for example ( https://aur.archlinux.org/packages.php?ID=43719), it depends on quite a few cabal2arch converted hackageDB packages (and those packages will obviously depend on more cabal2arch converted packages). Now this isn't an issue if 1. You have libraries installed through archlinux's AUR *and* 2. The dependencies happen to be the most up to date dependencies that are available for Archlinux AUR Point #1 is a concern for people that use cabal install for libraries, Point #2 is a general issue that effects any haskell program that doesn't happen to use the newest packages (either directly or indirectly). In the leksah example, some of those packages it depends on are outdated, but you obviously can't install those through AUR anymore, and then this whole cabal2arch mess starts happening with manual dependency tracking that I was talking about earlier (and what I refer to in regards to granularity). Currently haskell binaries/programs expect their dependencies to be installed via AUR packages, where as what I am saying (for the people that have installed their libraries through cabal) that there should be a PKGBUILD generator tool for haskell programs/binaries that scan for dependencies through cabal/ghc-pkg (and not AUR). I also believe that generally speaking, people should be encouraged to use cabal install instead of AUR

Rémy.