Hi there, 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 [1]), 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@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@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 [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). 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 [6]. 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) [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. - 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. - 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 curious.) That is all for today. Thanks for your attention. Cheers, :g [1] http://hackage.haskell.org/packages/hackage.html [2] http://www.mono-project.com/Mono:FreeBSD [3] http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/bsd.mono.mk [4] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126012 [5] http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.xorg.mk?annotate=1.8 [6] http://people.freebsd.org/~pgj/patches/2008-11-01/cabal-install-freebsd.tar.... [7] http://www.marcuscom.com/marcusmerge.8.html [8] http://bsd-sharp.googlecode.com/files/portshaker-0.0.8.tar.gz
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
Hello Ashish, Sorry for the late answer.
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 :).
Okay :)
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. [..]
Okay.
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.
I saw that BSDSharpers are doing it this way: they have an SVN repository where they put their stuff, and they have a ports guy who helps them to commit. As far as I have seen, they have periodical updates to the official tree, they heavily test their changes and then they submit a PR (like [1]). They track some ports that they actually do not maintain, but test for compatibility. Regards, :g [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/129724
On Sat, Jan 17, 2009 at 01:08:16AM +0100, Gabor PALI
Hi there,
Hi Gabor,
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...)
This is also my point of view; I prefer the mailing list and the e-mail over any other communication method. It's very clean and mostly is for ever.
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.
Thank you for this your accuracy, only now I read all these things.
- 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 [1]), 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)
This is, also for me, the best way to go. My interests are for the infrastructure, WxHaskell and for the Haskell software related to: Natural Language Processing Dynamic epistemic logic Theorem provers
- 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 haven't any important objection about this, but fixing the maintainer in this way reduces, for me, the level of responsibility and attention to each single haskell port.
- Elimination of the "-ghc" suffix: Samy advised to get rid of those "-ghc" suffixes in the port names. I asked haskell@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.
About this I think that it's not so a good idea, at least at this moment. Actually the haskell compilers are in development, and the ports with -ghc suffix are directly connected with the source of ghc and the ghc libraries. So, for me, it is better implementing a system turned towards the future, considering, at least, GHC Hugs nhc98 Yhc, and eventually also, if it needs, to keep more ghc versions in the port tree.
- Composition of a "bsd.haskell.mk": It is a must, nobody can deny.
This was my first concern.
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.
Well this is a good point! :-) I developed the first bsd.haskell.mk and the first bsd.wxhaskell.mk storing them at the heart of a given port, and my first Pr for it was submitted with the intention to simplify my life: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/124047 but at the end I changed all and, even though I knew all about the burden of several port management tests, I chose to place both the files in the port/Mk directory: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126012 The reason is very simple. The major problem with bsd.port.mk, bsd.port.pre.mk, bsd.port.post.mk, bsd.port.options.mk and friends is the variable expansion. It's very hard to control the sequence of variable expansion and the flow of Makefile of a single haskell port, if the central file bsd.haskell.mk is stored in another directory that the ports/Mk one. You can check the differences between the two Prs above to understand this. Maintaining the first system is harder.
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).
I'd have to study this solution, but I think that the advantages are minimal.
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.
My bsd.haskell.mk solution reduces the lines to about 5/10 (I tried with many different ports).
- Interference(?) with cabal-install: A few months ago, I created a preliminary port for cabal-install [6]. 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.
I don't think that it exists a simple solution, because the ports system is very tight about choices and frankly the majority of haskell software is in beta status, then It's better to have a single simple choice without mixing; and also the parsing is more complicated that a simple bsd.haskell.mk file.
- 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.
I have to see the portshaker solution, because I don't know it; I didn't never use the mono infrastructure.
- 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 curious.)
During this month I'll take many tests at the University, but I'll try to check if there are problems of compatibility. Giuseppe Pilichi
Hi Giuseppe, Sorry for the late answer.
I'm Giuseppe and I'm a contributor to FreeBSD ports:
Welcome!
I'm started some month ago, introducing the possibility to compile the developer documentation for every haskell ports with ghc.
Would not be better to have these ports merged? If I recall correctly, Samy already said something like that on IRC a while ago. However, it is a still an open question(?) what to do with libraries and their documentation. In ports of Ashish and mine, we respect the NOPORTDOCS variable, so these ports could be installed with or without documentation by setting this.
Now I'd like to point out some question and answer, at the best of my possibilities, to the questions that Gabor underlined.
Thanks for the credit, but at the moment, I am only a doc committer who is interested in using functional programming languages on FreeBSD, and accidentally has (almost) direct access the ports tree :P
1) My first question is how I could become a named developer in this team like the current developers:
I do not know who is maintaining the effort's web page, but I would point to Samy. He is the administrator here. I do not have any objection to include you. The more developer we have, the more we can progress.
2) I see that the git system was chosen; then which are the ideas about the future structure of this repository and its maintenance, or committing policy.
Ashish already leaked a few lines about this to the mailing list: we (are going to) have a master tree with the official ports, and a haskell branch where the contributions can go. I do not know about any (documented) committing policy, but it might look like the following (feel free to criticize): - work on the git repository, - test its content on a tinderbox (even periodically, mainly on i386 and amd64), - extract a patch for the official tree, - submit a PR for the update in the official tree, - get it reviewed, - and finally commit.
3) My two primary interests are developing a bsd.haskell.mk file, with the corresponding infrastructure and importing the WxHaskell libraries, and I hope someone can help me in this work.
One of first our goals to establish such an .mk file, so you are not alone at all :)
Then I want to answer to Gabor: [..] I haven't any important objection about this, but fixing the maintainer in this way reduces, for me, the level of responsibility and attention to each single haskell port.
I do not think you would be bored when we will have more than many hundreds of hs-* ports :P [..]
Actually the haskell compilers are in development, and the ports with -ghc suffix are directly connected with the source of ghc and the ghc libraries. So, for me, it is better implementing a system turned towards the future, considering, at least, GHC Hugs nhc98 Yhc, and eventually also, if it needs, to keep more ghc versions in the port tree.
Well, that makes sense indeed. By the way, I am getting afraid of GHC 6.10.x, since not all hackage builds with it currently (still). I think it would imply a separate port for the new GHC version. Maybe we should offer more interfaces for Haskell ports (e.g. one for cabal, one for hugs, and so on) in the bsd.haskell.mk. [..]
The major problem with bsd.port.mk, bsd.port.pre.mk, bsd.port.post.mk, bsd.port.options.mk and friends is the variable expansion. It's very hard to control the sequence of variable expansion and the flow of Makefile of a single haskell port, if the central file bsd.haskell.mk is stored in another directory that the ports/Mk one. You can check the differences between the two Prs above to understand this. Maintaining the first system is harder.
I thought of this just because BSDSharpers managed to solve these problems somehow. Okay, I will check out the referenced PRs. Thank you for pointing this out! [..]
My bsd.haskell.mk solution reduces the lines to about 5/10 (I tried with many different ports).
Hm, sounds interesting...
- Interference(?) with cabal-install [..] I don't think that it exists a simple solution, because the ports system is very tight about choices and frankly the majority of haskell software is in beta status, then It's better to have a single simple choice without mixing; and also the parsing is more complicated that a simple bsd.haskell.mk file.
Okay, let's ignore this issue for a while. :g
Hi Gabor,
On Mon, Jan 19, 2009 at 11:30:53PM +0100, Gabor Pali
I'm started some month ago, introducing the possibility to compile the developer documentation for every haskell ports with ghc.
Would not be better to have these ports merged? If I recall correctly, Samy already said something like that on IRC a while ago. However, it is a still an open question(?) what to do with libraries and their documentation. In ports of Ashish and mine, we respect the NOPORTDOCS variable, so these ports could be installed with or without documentation by setting this.
I'm sorry but I referred to the pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120975
1) My first question is how I could become a named developer in this team like the current developers:
I do not know who is maintaining the effort's web page, but I would point to Samy. He is the administrator here. I do not have any objection to include you. The more developer we have, the more we can progress.
Thank you for your credit; so I will ask Samy.
I haven't any important objection about this, but fixing the maintainer in this way reduces, for me, the level of responsibility and attention to each single haskell port.
I do not think you would be bored when we will have more than many hundreds of hs-* ports :P
Well I understand the problem but there are, at least, two points: 1) Sorry for the simple example (perhaps I don't hit the mark), but the majority of ports (thousands) depends on the compiler gcc and it isn't a problem having a different maintainer for each port. I don't think this is unmanageable. 2) Exist a "contributors list": http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/index.html and this is connected with each single named maintainer. In any way this isn't, definitely, a problem for me.
problems somehow. Okay, I will check out the referenced PRs. Thank you for pointing this out!
Thanks, I'd like you could weight my work and give me some suggestions. Giuseppe
participants (3)
-
Gabor PALI -
Jacula Modyun -
wahjava.ml＠gmail.com