Near past, present & future

Hi guys, As some of you may have noticed (perhaps with some pain), ghc-6.10.1 has been in testing for over a week now. Some performance regressions have been noticed, and some packages fail to build on it (most due to trivial problems). That's why it won't be coming to extra too soon. Nevertheless, I'm using it as my main platform for development, and it works well. Presently, the next big thing will be the Haskell Platform, which is basically a bundle of important packages. We will try to get the packages in it to extra, with a "haskell-platform" group defined. So pacman -S haskell-platform should get you all the goodies now and forever. All this is good. Now for a bit of controversy. I'm not very happy about how AUR works for us. We get good PKGBUILDs and rather painless installation through yaourt, but it feels quite clumsy to me. For at least the following reasons: 1) When we update ghc, there's no good way to update all the packages in AUR that depend on it. Best way to cleanup is pacman -Rc cabal-install, which kinda works but... And if I go back to the other ghc version (like I often did when playing with 6.8.2 and 6.10.1), my old packages are lost. 2) Pacman just doesn't support the sort of versioning we'd need for this. By principle. 3) yaourt often builds dependencies twice. Perhaps just a simple bug in yaourt. There's a simple solution to all these problems: for packages outside the Haskell Platform, we start using cabal-install. This has worked for me very well, and I'm not sure if I see why we should have Arch packages for everything. Of course also we would have some higher profile stuff in extra (like darcs) and community (like xmonad). Any feelings? Rest assured, I'm not gonna go at this blindly. --vk (dons an asbestos suit)

I've a longer discussion prepared, but would like to also start a discussion about 2009 goals for the Haskell support on our distro. * how are people using the Haskell packages? * via yaourt? * via cabal-install? * what support is missing? * what would they like to see Haskell support on Arch look like a year from now? Thoughts? -- Don

2008/11/15 Don Stewart
I've a longer discussion prepared, but would like to also start a discussion about 2009 goals for the Haskell support on our distro.
Sometimes we need to package haskell packages which have their dependencies in AUR. I suppose for most common Haskell applications, the dependencies will be taken care of by having haskell-platform installed, but it would be nice to have some way of having the dependency auto-updated in the case it has to be added to [community] manually. BTW, what happened to the x86_64 repository for Haskell packages? As vegai mentioned, it is certainly not neccessary to have all packages of Haskell packaged :) But it can be done easily now, we just need a server to build the packages. At least Haskell PKGBUILDs should continue to be uploaded to AUR. -- Abhishek

"Abhishek" == Abhishek Dasgupta
writes:
Abhisek> Sometimes we need to package haskell packages which have Abhishek> their dependencies in AUR. I suppose for most common Haskell Abhishek> applications, the dependencies will be taken care of by having Abhishek> haskell-platform installed, but it would be nice to have some Abhishek> way of having the dependency auto-updated in the case it has Abhishek> to be added to [community] manually. Solution for everything would be to have hacman (or pinky as suggested in #arch-haskell) - wrapper for pacman written in Haskell, using libalpm and enhanced to use cabal-install. Some advantages would be: 1) all the deps would be (hopefully) properly resolved by using cabal-install 2) the hacman (pinky) would be (hopefully) more robust and feature-wise than yaourt 3) hacman (pinky) could be used by non-haskell users exposing to to the wonderful land of Haskell (e.g. there is nice himerge GUI for Gentoo written in Haskell), i.e Real-World-Haskell used for system admin 4) no need for cabal2arch 'cause we would use *.cabal descriptions directly from Hackage 5) single tool to handle all Arch-related system tasks I'm not sure how difficult it would be to write it to support all the above features, but I'm open for flaming ;) Sincerely, Gour

2008/11/15 Gour
Solution for everything would be to have hacman (or pinky as suggested in #arch-haskell) - wrapper for pacman written in Haskell, using libalpm and enhanced to use cabal-install.
What about other automated systems for installing stuff? It would be nice to have them too and not be restricted to just Haskell: * RubyGems (gem install...) * PyPi (don't know if there's automated installer here as well) * Perl (cpan, though Firmicus has a script to convert them to PKGBUILDs) A generic API to which these kind of installation systems could be added as modules would be really cool.
Some advantages would be:
1) all the deps would be (hopefully) properly resolved by using cabal-install
2) the hacman (pinky) would be (hopefully) more robust and feature-wise than yaourt
Such a tool in Haskell would be really nice. I've not much idea of Haskell, but it is indeed beautiful... I just can't wrap my head around functional programming much. Simple programs are OK, but anything a bit more complicated makes me run back to Python :)
3) hacman (pinky) could be used by non-haskell users exposing to to the wonderful land of Haskell (e.g. there is nice himerge GUI for Gentoo written in Haskell), i.e Real-World-Haskell used for system admin
4) no need for cabal2arch 'cause we would use *.cabal descriptions directly from Hackage
5) single tool to handle all Arch-related system tasks
One tool to rule them all One tool to bring them to Arch And in simplicity bind them. :D -- Abhishek

"Vesa" == Vesa Kaihlavirta
writes:
Vesa> Nevertheless, I'm using it as my main platform for development, Vesa> and it works well. Vesa> Presently, the next big thing will be the Haskell Platform, which Vesa> is basically a bundle of important packages. We will try to get Vesa> the packages in it to extra, with a "haskell-platform" group Vesa> defined. So pacman -S haskell-platform should get you all the Vesa> goodies now and forever. Great. Vesa> All this is good. Now for a bit of controversy. :-) Vesa> 1) When we update ghc, there's no good way to update all the Vesa> packages in AUR that depend on it. Best way to cleanup is pacman Vesa> -Rc cabal-install, which kinda works but... And if I go back to Vesa> the other ghc version (like I often did when playing with 6.8.2 Vesa> and 6.10.1), my old packages are lost. Yes, that's painful. Vesa> 3) yaourt often builds dependencies twice. Perhaps just a simple Vesa> bug in yaourt. Ahh, cool...I'm not the same being bitten too often with it... Vesa> There's a simple solution to all these problems: for packages Vesa> outside the Haskell Platform, we start using cabal-install. As I mentioned on #archlinux yesterday - there is not 'uninstall' option for cabal-install. Vesa> This has worked for me very well, and I'm not sure if I see why we Vesa> should have Arch packages for everything. I agree there is no need for having all the packages, but, thanks to Don, it's very easy to get 'em all via cabal2arch. Vesa> Of course also we would have some higher profile stuff in extra Vesa> (like darcs) and community (like xmonad). It would be nice to have GUI lib(s) like gtk2hs as well considering other languages (Perl, Python) Sincerely, Gour

Ok. So what do we do next? AUR is now up to date. cabal2arch is working with 6.10/new cabal. Quick thoughts: * xmonad 0.8.1 this week * move 6.10 from testing -- i'm really happy with how many packages are working now, and i've updated most of AUR to work with 6.10 * cabal-install in binary form Then the platform, which means some non-Arch work, and design of the meta-package. We can make Arch the testing system for the platform vpkaihla:
Hi guys,
As some of you may have noticed (perhaps with some pain), ghc-6.10.1 has been in testing for over a week now. Some performance regressions have been noticed, and some packages fail to build on it (most due to trivial problems). That's why it won't be coming to extra too soon. Nevertheless, I'm using it as my main platform for development, and it works well.
Presently, the next big thing will be the Haskell Platform, which is basically a bundle of important packages. We will try to get the packages in it to extra, with a "haskell-platform" group defined. So pacman -S haskell-platform should get you all the goodies now and forever.
All this is good. Now for a bit of controversy.
I'm not very happy about how AUR works for us. We get good PKGBUILDs and rather painless installation through yaourt, but it feels quite clumsy to me. For at least the following reasons:
1) When we update ghc, there's no good way to update all the packages in AUR that depend on it. Best way to cleanup is pacman -Rc cabal-install, which kinda works but... And if I go back to the other ghc version (like I often did when playing with 6.8.2 and 6.10.1), my old packages are lost.
2) Pacman just doesn't support the sort of versioning we'd need for this. By principle.
3) yaourt often builds dependencies twice. Perhaps just a simple bug in yaourt.
There's a simple solution to all these problems: for packages outside the Haskell Platform, we start using cabal-install. This has worked for me very well, and I'm not sure if I see why we should have Arch packages for everything. Of course also we would have some higher profile stuff in extra (like darcs) and community (like xmonad).
Any feelings? Rest assured, I'm not gonna go at this blindly.
--vk (dons an asbestos suit) _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

On Mon, Jan 12, 2009 at 8:48 AM, Don Stewart
Ok. So what do we do next?
AUR is now up to date. cabal2arch is working with 6.10/new cabal.
Quick thoughts:
* xmonad 0.8.1 this week * move 6.10 from testing -- i'm really happy with how many packages are working now, and i've updated most of AUR to work with 6.10 * cabal-install in binary form
Sounds like a plan. I'll start bringing cabal-install and its dependencies to [community] (or does it need to be extra?). I'm a bit busy at work this week, but hopefully I'll manage it before you get xmonad-0.8.1 out. --vk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Don Stewart
AUR is now up to date. cabal2arch is working with 6.10/new cabal. * xmonad 0.8.1 this week * move 6.10 from testing * cabal-install in binary form
fantastic work everyone. arch is on its way to becoming the best platform for haskell developers. as always, let me know if you need help brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklreRUACgkQxRg3RkRK91M05QCeKAAX0hOBIBHpcAPFzbe/Hap2 sj4AniZuTZCig3pSQHPTo1E9wsKBwXQ5 =Ep+s -----END PGP SIGNATURE-----

"Don" == Don Stewart
writes: Hi,
Don> Ok. So what do we do next? I met several people on #arch who ask about i686 overlay and it would be nice to have a working one for x86_64 as well. Having some sort of bug-tracker for arch-haskell would be nice as well which could be used by (new) arch-haskell users to submit new pkgbuilds. Otoh, I saw e.g. dcoutts saying that most of the haskell pkgs (on gentoo) he installs via cabal-install, so the question is how could we improve situation on Arch: 1) improving the packager (e.g. yaourt, hacman) to use cabal-install or 2) encouraging use of cabal-install or 3) something else? Don> Then the platform, which means some non-Arch work, and design of Don> the meta-package. We can make Arch the testing system for the Don> platform What do you think what percentage of packages will be covered with the platform for 'average' (if such thing exists) haskell user? Sincerely, Gour

* cabal-install in binary form
This is now for the most part done: I added haskell-zlib, haskell-http, haskell-cabal and cabal-install to the community svn repo. I'll upload the binaries as we move to ghc-6.10. Your locally installed cabal-install and cabalized packages probably will conflict with these. --vk

vpkaihla:
* cabal-install in binary form
This is now for the most part done: I added haskell-zlib, haskell-http, haskell-cabal and cabal-install to the community svn repo. I'll upload the binaries as we move to ghc-6.10.
Your locally installed cabal-install and cabalized packages probably will conflict with these.
Yes, and now pacman -S cabal-install is working.
participants (5)
-
Abhishek Dasgupta
-
brad clawsie
-
Don Stewart
-
Gour
-
Vesa Kaihlavirta