I've created an ebuild for the unison bidirectional cross-platform file synchronization package. (See http://www.cis.upenn.edu/~bcpierce/unison/ for details). I've found this package to be one of the best for keeping files in sync between two (or more) machines. The ebuild is contained in the attached tarball. Dependencies are a little complex, but i'll try to explain them here: As unison is written in OCaml (which is part of Gentoo), this is naturally a build-time dependency. For GTK+ support, unison also requires the LablGTK package (an Ebuild for which is also included in the attached tarball). The LablGTK package in turn requires LablGL for OpenGL support (all this is optional, based on the "USE" variable). If GNOME support is specified in the "USE" variable, the LablGTK ebuild will also automatically compile with support for that. The LablGL package ebuild is also contained in the attached tarball. Note that unison only requires LablGTK and OCaml at build-time, therefore these have been entered as build-time dependencies, while GTK+ is a runtime dependency. Hope that explains it all ;) Final note: I've created a separate category "dev-ocaml" for the LablGTK and LablGL packages (in the spirit of extensions for other languages). This, of course, needs to be added to the "/usr/portage/profiles/categories" file.
Created attachment 1233 [details] unison-2.9.1 ebuild
There was a small bug in the dependencies for LablGTK (the package categories for the opengl optional dependencies were missing). I've attached a revised ebuild.
Created attachment 1237 [details] revised LablGTK ebuild
*sigh* sorry about this... I've just discovered that the LablGL & LablGTK extensions were being compiled into bytecode only (I missed the "opt" makefile targets). This meant that unison could only be compiled to bytecode (which, for some reason, doesn't work properly). This has been fixed, and I've attached a new tarball containing revised versions of all the ebuilds. This revision has been verified to actually work :)
Created attachment 1238 [details] unison-2.9.1 ebuild (revision 2)
Hi Bardur. Thanks for a submission and sorry for taking so long to get to this bug. Well, part of the reason is that I was skipping this one a few times bacause it requires creation of a new category (and contains two ebuilds - the proper procedure is to create two bugs and make one depend on another BTW). I am going to raise the question about creation of a new category for ocaml related libs/apps. Is the need for this category based solely on these two packages? It would help me to persuade other developers in the need for a new category if there were other packages that would benefit from such addition. May be you know about any package presently in the portage tree that could be moved? George
> Well, part of the reason is that I was skipping this one a few times bacause > it requires creation of a new category (and contains two ebuilds - > the proper procedure is to create two bugs and make one depend on another > BTW). Ah, sorry about that. I'm not that experienced with bugzilla (yet! :)), so I don't really know whats possible. But I will definitely use that feature in future. :) > I am going to raise the question about creation of a new category for ocaml > related libs/apps. Is the need for this category based solely on these two > packages? Presently, only the two packages LablGTK and LablGL should go into dev-ocaml. > It would help me to persuade other developers in the need for a new > category if there were other packages that would benefit from such addition. > Maybe you know about any package presently in the portage tree that could be > moved? A quick grep through the portage tree reveals that the are currently no other packages which depend on ocaml. However, there are few ocaml libraries/extensions (for example, http://www.ai.univie.ac.at/~markus/home/ocaml_sources.html has some quite interesting stuff) which I would like to add to portage, once this (hopefully) gets accepted into Portage. I just think it would be much cleaner to just add a category now, than to create ocaml-LablGTK, ocaml-LablGL, ocaml-XXX packages, and then later realize that a new category is needed and have to move all those packages. I don't really know the internals of Portage, so if there are efficiency reasons/other reasons why adding a category is a big deal, I could probably be persuaded to change these packages so that they would reside in another (already existing) category.
Hi Bardur >I just think it would be much cleaner to just add a category now, than to >create ocaml-LablGTK, ocaml-LablGL, ocaml-XXX packages, and then later realize >that a new category is needed and have to move all those packages. I agree with that. The reasons to think a bit and not just bluntly go on with any category addition are not on the side of efficiency but rather have to do with the fact that we already have a large number of categories. Thus we need to ensure that a new category addition will benefit our users instead of just adding bloat to the portage tree (and therefore addition of a new category normally needs to be discussed among core group). Only two packages seems to be a bit too little to warrant a new category. However since you promice to add more packages that will go into it, this should be fine. I have submitted a proposal to add a category. So far there were no objections. I will wait until Monday/Tuesday and then create a category and commit your ebuilds. If you want to add more ebuilds to this caegory you can go ahead and submit them; you can assign them to me. Please follow the "one ebuild per submission" guideline (this makes it easier to process them). You can specify the dependencies by listing them in the provided input field right under attachments pane. Thanks for your work! George
Hi Bardur Sorry for a prolonged silence, I somehow thought that I posted an update here. So here it goes: As a result of discussion I will create somewhat broader category: dev-ml. This will include sml/nj, caml, and other (strict) ML languages in addition to ocaml related stuff. Also it was decided that just two packages is a bit too little to start off with (and other mentioned ml packages are not in the portage as of yet unless you know anything related). I would like to have at least one more submision into this category (I remember you promised to do few more ebuilds), or at least your word on when you will be able to add some more.. If you are unable to do any more commits in near future, no problem. I may commit them them under dev-libs for now (moving packages is not such a big deal, however I would definitely prefer to start off cleanly). Thanks! George
As requested, I've created an Ebuild for an OCaml interface to the libpcre library. See bug #4297.
Hi Bardur. added dev-ml category and committed both libs. Will shortly add unison itself. George
committed unison. Thanks Bardur! George