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/