[Freebsd-haskell] What's the point of the cabal freebsd ports?

[Gabor PALI]

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/