What's the point of the cabal freebsd ports?
Some of the cabal ports have there own freebsd ports but not many and the ones that are there are usually old anyway. Luckily the cabal packages on hackage work just fine and I was installing manually each one like: runhaskell Setup.lhs configure --user runhaskell Setup.lhs build runhaskell Setup.lhs install because I was assuming that there was some reason why cabal-install could not be used on freebsd. Eventually I realized that this was not true and installing the packages that have lots of dependencies actually became more worthwhile as it was very tedious before. I was then using cabal with the exception of choosing the port versions if they existed as if there would be some advantage in doing so. It wasn't long before I ran into a port that didn't build (maybe because it was old) so I tried letting cabal just pull the later one from hackage. This built just fine. I shall probably remove the other freebsd haskell ports from my system and replace with updated hackage ones. What's the point of all this? I think if freebsd only had ports for the basic stuff like haskell platform and other compilers then it could potentially make it easier for the devs/testers to finally get the updated ghc 6.12.1 version in the main tree. Sorry if this sounds harsh but it seems like the current setup is stale, messy and inconsistent which could be trimmed down, maintained + cabal is a package that really does need to be in the ports but currently isn't so. Thanks
Hello Tim, You may find an answer to your question in a recent blog entry (that I have posted earlier to this list [1]). For a longer (and more FreeBSD-oriented) explanation: On 03/28/10 16:30, Tim Matthews wrote:
Some of the cabal ports have there own freebsd ports but not many and the ones that are there are usually old anyway.
Yes, it is a known problem, but I am working on a new framework that will make porting and updating hackages trivial, and it is planned to be committed in a week (after the huge update commits). I am also mentoring new FreeBSD ports commiter who is actually dedicated to Haskell ports. Well, I do not see your PRs... :P At the moment 5% of all hackages is ported and 32% of them is outdated (more or less). And count a ports freeze in :D
Luckily the cabal packages on hackage work just fine and I was installing manually [..]
Great! Yesterday I was not so lucky when I wanted to install gitit via cabal-install (and I needed to patch strict-concurreny-0.2.3 and SMTPClient-1.0.1 a bit to make the things work).
because I was assuming that there was some reason why cabal-install could not be used on freebsd. Eventually I realized that this was not true and installing the packages that have lots of dependencies actually became more worthwhile as it was very tedious before.
Of course, cabal-install can be used on FreeBSD without any problems (if one does not count the problems of the hackages themselves...).
I was then using cabal with the exception of choosing the port versions if they existed as if there would be some advantage in doing so. It wasn't long before I ran into a port that didn't build (maybe because it was old) so I tried letting cabal just pull the later one from hackage.
Some people might prefer using binary packages since they do not have enough resources to (re)compile everything like when using cabal-install. Others might prefer the possibility to be able to remove these packages as well. And a few ones prefer when everything just works out-of-the-box (i.e. well-tested), without further hacking.
This built just fine. I shall probably remove the other freebsd haskell ports from my system and replace with updated hackage ones.
You are free to do it, no hard feelings :)
What's the point of all this? I think if freebsd only had ports for the basic stuff like haskell platform and other compilers then it could potentially make it easier for the devs/testers to finally get the updated ghc 6.12.1 version in the main tree.
Your proposal sounds reasonable. My plans regarding addressing these problems are as follows: - Introduce a new framework for hackage ports (enables faster updating). - Introduce an automatic hackage to port converter using the new framework (enables faster porting). - Add a port for Haskell Platform that conflicts with lang/ghc and all hs-* ports, so everybody may use cabal-install instead of FreeBSD ports. Yay! - Update lang/ghc to GHC 6.12.x, if all the (sup)ported hackages build with it correctly. - Introduce a lang/ghc-devel port for upcoming (but not yet completely supported) GHC releases, so developers and testers may work with it.
Sorry if this sounds harsh but it seems like the current setup is stale, messy and inconsistent which could be trimmed down, maintained + cabal is a package that really does need to be in the ports but currently isn't so.
Thank you for your comments. Cheers, :g [1] http://www.haskell.org/pipermail/freebsd-haskell/2010-March/000172.html
Hi Gabor thanks for the reply.
....................Great! Yesterday I was not so lucky when I wanted to install gitit via cabal-install (and I needed to patch strict-concurreny-0.2.3 and SMTPClient-1.0.1 a bit to make the things work).
Is this always the best way to do it as opposed to submitting a patch that makes it freebsd compatible to the port maintainer?
My plans regarding addressing these problems are as follows:
- Introduce a new framework for hackage ports (enables faster updating).
- Introduce an automatic hackage to port converter using the new framework (enables faster porting).
When a haskell developer announces some new package and it's available on hackage, it would be great if it could be installed instantly despite being a freebsd user. Your blog post points out that cabal isn't everything but how fast would this 'faster updating' be. If we could completely remove the human from the system and have a tool that monitors hackage and creates ports as it happens then it would be fast enough. It wouldn't be tested but at least proper port management, uninstallation etc work with it until it then becomes modified to include patches. One thing I think we really cannot have is the dual of freebsd ports as-well as cabal install packages. Even if I try to install just using cabal install there will probably be a port that depends on a hs-* port, it will then try to install this but it already exists in ~/.cabal/ and this we be a big source of problems. Therefore if we want any freebsd ports of hackages then I think completly automated creation of up to date hackages is an absolute must.
- Update lang/ghc to GHC 6.12.x, if all the (sup)ported hackages build with it correctly.
I think some of the packages on hackage still don't build with ghc 6.12.1. Also some (or at least 1) of the freebsd hs-* ports don't build. I think the port hs-datetime was the one I couldn't build and this is still using 6.10.4. Also have you looked at how the other major operating systems such as redhat, ubuntu, opensuse, solaris, archlinux etc are doing this? Are they all just making do with having all there hackages out of package management?
Hello there, On 03/29/10 02:12, Tim Matthews wrote:
Is this always the best way to do it as opposed to submitting a patch that makes it freebsd compatible to the port maintainer?
It was not really a FreeBSD-related problem. There was some interface change in one of the hackages that broke SMTPClient, for example. Yes, you are right, generally The Right Way(TM) is to report these kind of problems and send patches to the maintainer, but I needed gitit and I simply I did not want to spend time on such formalities. (I like sharpening my diffs, so my hacks that make things work first might not be the ones that they should be in the end.) Certainly, when I am building an official FreeBSD port, the best way is just to do so. Though in my case, gitit would require a tons of hackages to be ported (including happstack), so that is why I used cabal-install. It would be nice to have a pre-compiled package for gitit one day, though.
When a haskell developer announces some new package [..] it would be great if it could be installed instantly despite being a freebsd user.
It is nearly impossible, sorry. (Feel free to correct me!) Some of the obvious reasons to me: - Fresh hackages are very experimental, I do not see that they are actually tested before each upload. An example of it would be the SMTPClient indicent. For FreeBSD ports, it is a general policy to do a build testing of the dependent ports before each commit. Yeah, it takes time but ask twice, commit once, apologize zero times. (Though we had an unlucky png shared lib update recently, but usually it is not the case.) As a consequence, it is worth to wait for the fixes and check (and guarantee!) that everything works well, i.e. do some engineering work. Broken ports are worse than having no ports at all. - Due to periodical releases, the FreeBSD ports tree is frozen ("locked"), i.e. you cannot add / update / remove ports, only fixing them is allowed. This is a short period (one or two weeks) followed by a partial thaw that enables adding new ports and limited way of updating (two to four weeks, maybe). It usually happens two times per year. Therefore one cannot update ports as one wants. There are rules to be observed. I think this is one of things characterizes FreeBSD the most. - Immediate porting would also require a direct and total mapping from Cabal packages to FreeBSD ports. Well, theoretically it is possible, I am working on it :P But because of the required engineering work I mentioned above, humans just cannot be dropped out of the system, and they will always be a bottleneck.
If we could completely remove the human from the system and have a tool that monitors hackage and creates ports as it happens then it would be fast enough.
First half of the job is done. Wait for Saturday midnight and you will receive an email from the HackageDB Port Checking Service :P It is actually a small script that monitors HackageDB weekly. It is mainly used for nagging people around here, but it can be easily modified to track new hackages as well (or so produce some fancy statistics, etc).
It wouldn't be tested but at least proper port management, uninstallation etc work with it until it then becomes modified to include patches.
It is possible do it that way, many porting subprojects already maintain their own experimental tree, e.g. KDE on FreeBSD [1], The FreeBSD GNOME Project [2], BSD# [3]. We may experiment with this approach later on, as soon as somebody provides me the necessary resources. As a matter of fact, I have just built a system for FreeBSD ports development for myself (some version controlling stuff combined with a Tinderbox), but I do not want to publish it yet. Hmmm, there might be an extension of it to pull & add/update/remove hackages automatically by following this scheme: - Detect changes in HackageDB (daily for example). - Bring the changes (add/remove/update ports) to a ports tree instance. - Tinderbox the results, create build logs. - Create nice eye-candy statistics. The automated conversion is the thing that is missing for this at the moment. But it is very near, so we will see...
One thing I think we really cannot have is the dual of freebsd ports as-well as cabal install packages.
Nope. But it is okay to use one of the approaches by *excluding* the other. I want to offer a choice: for "fast-track users", I would recommend to use Haskell Platform with cabal-install and never look back; but for "mortals" I would rather recommend to use ports/packages.
Even if I try to install just using cabal install there will probably be a port that depends on a hs-* port, it will then try to install this but it already exists in ~/.cabal/ and this we be a big source of problems.
The solution is trivial: do not mix ports with cabal-install. Never ever.
Therefore if we want any freebsd ports of hackages then I think completly automated creation of up to date hackages is an absolute must.
I would not say that. A distilled, well-organized and well-tested set of continuously updated hackages as ports might be more than enough. Think of it as a "Haskell FreeBSD Platform": Stuff in Haskell Platform ported to FreeBSD, extended with some others. It is true that HackageDB contains nearly 2K packages nowadays, but I am sure that many of them simply does not worth to be ported (yet). A solution would be to maintain a "wishlist" based on opinion of users and/or make them send a PR on each hackage they want to see on FreeBSD :P Could you tell me how many hackages are there in your `ghc-pkg list` output?
I think some of the packages on hackage still don't build with ghc 6.12.1.
That is why GHC 6.12.1 should be in lang/ghc-devel. But Don Stewart recently announced the next version of Haskell Platform that builds upon that. More headache. It makes me keep thinking that Haskell Platform should be really an independent port of its own.
Also some (or at least 1) of the freebsd hs-* ports don't build. I think the port hs-datetime was the one I couldn't build and this is still using 6.10.4.
Do we have a hs-datetime port? Where?
Also have you looked at how the other major operating systems such as redhat, ubuntu, opensuse, solaris, archlinux etc are doing this?
Arch Linux: cabal2arch [4]. Redhat / Fedora / (open)SUSE: cabal2spec and cabal-rpm [5][6]. (Open)Solaris: only GHC + cabal-install is ported [7]. Debian / Ubuntu: cabalDebianTemplate [8]. Gentoo Linux: haskell-updater [9]. MacOS X: cabal-macosx [10]. Slackware Linux: HSlackBuilder [11].
Are they all just making do with having all there hackages out of package management?
It does not seem so. Just a quick note on my previous email: we still need to wait for a while, since GNOME and KDE updates will hit the FreeBSD ports tree in a couple of days, and one might expect more unstability :( But if you want to see the new framework I can post my .mk includes and some "nouveau" ports just for teasing :) Cheers, :g [1] http://freebsd.kde.org/ [2] http://www.freebsd.org/gnome/ [3] http://code.google.com/p/bsd-sharp/ [4] http://code.haskell.org/~dons/code/cabal2arch/ [5] https://fedorahosted.org/cabal2spec/ [6] http://www.serpentine.com/blog/software/cabal-rpm/ [7] http://code.google.com/p/opensolaris-lang/downloads/list [8] http://www.n-heptane.com/nhlab/repos/cabalDebianTemplate/ [9] http://haskell.org/haskellwiki/Gentoo#haskell-updater [10] http://github.com/gimbo/cabal-macosx [11] http://code.haskell.org/~arossato/hslackbuilder/
participants (2)
-
Gabor PALI -
Tim Matthews