[Freebsd-haskell] Some Topics to Discuss...
pgj at FreeBSD.org
Fri Jan 16 19:08:16 EST 2009
Since we have an own mailing list at last, I would like to raise some
issues to be discussed. I do not why, but I prefer e-mail over any
other communication method, because it is stored (at several places)
and I have time to process the input and produce the output :) (And
it also strikes a balance between the different time zones we live
in.) So, excuse me I am using this method, but I feel this the most
"official" way to discuss any effort-related issue (but please, refute
me if I am wrong...)
I have collected some issues (without the claim for completeness) to
start some threads and discussions on this list. Feel free to pick
any of the items to answer or express your ideas (even in a separate
thread) or raise other issues.
Sorry in advance if I touch things those have been settled on IRC. I
think the problems and the decisions regarding them should be
documented somehow, anyway.
- Range of ports we maintain: In my opinion, it would be useful to
identify which type of ports we maintain: in my first thoughts, it
would be interesting to maintain GHC and libraries (mostly found on
HackageDB ), but not complete applications (like Pandoc, that is
also available via HackageDB, but it is a standalone application
(however, it incorporates a library...) and it does not include the
"hs-" prefix in its port name in the FreeBSD ports tree). So, in
brief: I suggest to add and maintain "hs-*" packages and lang/ghc.
(More than enough :P)
- MAINTAINER field of the ports we maintain: To uniformize the effort,
I suggest to set the maintainer all of the maintained ports to
"freebsd-haskell at haskell.org" (address of this list), so any of the
members could easily fix and add new ports, etc. If somebody new
wants to tackle these ports, he or she should contact us first and
then delegate his or her patches though this list, and so on.
- Elimination of the "-ghc" suffix: Samy advised to get rid of those
"-ghc" suffixes in the port names. I asked haskell at freebsd.org guys
about this suffix, and Volker told me that it was used to identify the
ports that had been ported to GHC exactly. Since GHC is the center of
our efforts, I clearly agree with the elimination these suffixes. (I
do not whether it has been already done meanwhile, though.) But we
have to be careful with this, because many ports depend on hs- ports,
so this kind of "refactorizaton" might result a huge patch (what it is
not necessarily encouraged by FreeBSD porters)(?)
As a side note: packages with the "-ghc" suffix use a different
destination directory, I hope you know this. I think this should be
also be unified.
- Composition of a "bsd.haskell.mk": It is a must, nobody can deny.
In the first round, I do not think it should be placed right in the
"ports/Mk" directory, because people at the BSD# Project  (I think
I am going to refer them many times) store their own ".mk" file at the
heart of their ports, lang/mono . In my opinion, following this
behavior would save the initial efforts from the burden of several
port management tests and tasks ("experimental ports build" -- Mark
Linimon mentioned these in the PR where a bsd.haskell.mk was offered
). So, I suggest to add this file to the lang/ghc port first.
About its structure: I suggest to employ some "build magic" to make
its invocation automatic. For example, every port with the "hs-"
prefix (or in the "haskell" category) could automagically include this
.mk file. I do not think it would be hard to implement as this
technique has been already used by bsd.xorg.mk  (e.g. around line
The actual structure of this file should be derived from the current
hs-* ports -- I think it is easy, because many of these ports have a
lot of constructs in common, so I would say (without experimenting
with anything) their Makefiles could be even reduced to about 2-5
lines(!) (including the port name and version, may be the
dependencies) in an optimal case by a good .mk file. (But I am naive!
:)) I think this approach could even make us re-think whether a
cabal2port converter is really needed.
- Interference(?) with cabal-install: A few months ago, I created a
preliminary port for cabal-install . I think this or something
like that should be added to our collection, so "the real bleeding
edge" users do not have to wait for us with the ports. It is okay,
but it raises(?) an interesting problem: what if somebody starts to
use both the ports _and_ cabal-install and even accidentally mixes
them? (E.g. installs something with pkg_add then updates it from
cabal-install or deletes it, and so on -- vice versa) At the moment,
I do not see any trivial solution to this problem, so any comments
would be welcome.
- Merging our ports with the official FreeBSD ports tree: port trees
out of the official FreeBSD port tree (like KDE, GNOME, BSD# etc.) use
different techniques to merge ("engraft") their trees. Ashish
mentioned that FreeBSD does not have a standard method for implemeting
this when I mentioned the famous marcusmerge(8)  earlier. He was
not happy with this approach, but I found another meanwhile, called
portshaker  (from BSD#). I have not tried it yet, but it is a yet
another way to solve this problem.
- Quarterly Status Report: A short note on that we could advertise
ourselves in the recent FreeBSD Quarterly Status Report. However the
submission date past (Jan 14, 2009) for the latest one, but as I
taught, I think there might be a chance to push one more simple report
to Brad :) If I got some nods, I post a draft here and then to
monthly at . Of course, it is not a tragedy if we miss this, we can
supply it later on.
- Things to be Committed: I am (still) happy to tinderbuild and commit
Haskell port patches, but please, send me them in email if possible.
Note that I am not a ports committer, but with the help of Martin
Wilke (miwi@) I can work with these patches. Of course, the more
(active) committers on this list the better :)
- GHC 6.8.10: What is up with GHC? What are the exact obstacles to
get the latest version ported? Has anybody tried it? (I am just
That is all for today. Thanks for your attention.
More information about the FreeBSD-haskell