Gabor PALI writes:
Hi there,
Hi, Following are the issues which I think are *immediately* relevant and So, I'm replying to them inline. [snip]
- 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@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.
I agree with this. [snip]
- 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 [2] (I think I am going to refer them many times) store their own ".mk" file at the heart of their ports, lang/mono [3]. 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 [4]). 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 [5] (e.g. around line 53).
Maybe I'm not getting this right but I don't without fiddling with the files in ${PORTSDIR}/Mk you can achieve that auto-magic inclusion of bsd.haskell.mk in haskell related ports. I propose the way which xpi-* ports are following until we make it to the ${PORTSDIR}/Mk. All of the xpi-* ports directly include "xpi-adblock/Makefile.xpi". So I think this much of manual effort we can do :). [snip]
- 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) [7] earlier. He was not happy with this approach, but I found another meanwhile, called portshaker [8] (from BSD#). I have not tried it yet, but it is a yet another way to solve this problem.
Well my approach is to stop following the official ports tree in the officially documented way, but instead work on the ports tree from a git repository. The git repository is located at git.applicative.org and there (is|will be) a cron job which will keep git repository's master branch in sync with official one, the only thing which we have to do is to initially clone the repo from git.applicative.org and then keep pulling from the periodically instead of updating via portsnap or csup. 'git pull' will only fetch deltas like cvsup or portsnap. The similar method is being used by the funtoo.org (a derivative of Gentoo GNU/Linux), their HOWTO[1] can be consulted for details. For our ports, there will be separate branch "haskell" where we will push our changes. And we need to decide on a policy on how are we going to push changes to 'haskell' branch and then finally to the FreeBSD PR system.
- 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@. Of course, it is not a tragedy if we miss this, we can supply it later on.
An announcement will be great so anyone interested in the effort could join. References: [1] http://wiki.github.com/funtoo/portage/first-steps Regards -- Ashish SHUKLA