I would really like to upgrade OCaml in EPEL 5 to version 3.10.2.
The main reason is that much of the other software we'd like to ship with EPEL needs the new camlp4 [1], which was introduced with OCaml >= 3.10.0. (EPEL ships with OCaml 3.09.3 at present).
http://download.fedora.redhat.com/pub/epel/5/i386/repoview/ocaml.html
Backporting the software to the older OCaml is going to be very complicated. The two versions of camlp4 (< 3.10.0 and >= 3.10.0) are really incompatible. The newer one is much more featureful and is rapidly displacing older versions. Backporting just the newer camlp4 to the older compiler is also considered intractable, since the compiler and camlp4 are closely linked.
Now the downside to doing this is that it would require any OCaml users of EPEL 5 to recompile their software. This may just be a simple recompile, but there are also worst-case scenarios such as people using and relying on the old camlp4 who may have to make modifications of their software. So it's quite a big disruption for everyone. I'm also very aware that EPEL is supposed to be long-term stable.
Comments?
Rich.
[1] http://en.wikipedia.org/wiki/Camlp4 http://brion.inria.fr/gallium/index.php/Camlp4
2008/8/25, Richard W.M. Jones rjones@redhat.com:
I would really like to upgrade OCaml in EPEL 5 to version 3.10.2.
The main reason is that much of the other software we'd like to ship with EPEL needs the new camlp4 [1], which was introduced with OCaml >= 3.10.0. (EPEL ships with OCaml 3.09.3 at present).
As for me, I never afraid of updating to latest version :) Seriously speaking, the main difficulty in maintaining packages, is the total absence of feedback from users *before* any updates.
On Tue, Aug 26, 2008 at 12:10:14AM +0400, Peter Lemenkov wrote:
Seriously speaking, the main difficulty in maintaining packages, is the total absence of feedback from users *before* any updates.
Well yes, that is the problem. I'm aware of a number of OCaml / EPEL users. They mainly seem to be people using it to teach university courses ...
Rich.
On 08/26/2008 01:16 AM, Richard W.M. Jones wrote:
On Tue, Aug 26, 2008 at 12:10:14AM +0400, Peter Lemenkov wrote:
Seriously speaking, the main difficulty in maintaining packages, is the total absence of feedback from users *before* any updates.
Well yes, that is the problem. I'm aware of a number of OCaml / EPEL users. They mainly seem to be people using it to teach university courses ...
Rich.
Maybe you could leave the older ocaml as such and create a new ocaml5 ?
On Tue, Aug 26, 2008 at 01:26:59AM +0300, Manuel Wolfshant wrote:
On 08/26/2008 01:16 AM, Richard W.M. Jones wrote:
On Tue, Aug 26, 2008 at 12:10:14AM +0400, Peter Lemenkov wrote:
Seriously speaking, the main difficulty in maintaining packages, is the total absence of feedback from users *before* any updates.
Well yes, that is the problem. I'm aware of a number of OCaml / EPEL users. They mainly seem to be people using it to teach university courses ...
Rich.
Maybe you could leave the older ocaml as such and create a new ocaml5 ?
That's another possibility. But I've never seen a working parallel OCaml compiler install. It's definitely not as easy as it is with gcc to do parallel / compat installs ... A question for upstream, I think.
Rich.
On Mon, Aug 25, 2008 at 5:24 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Tue, Aug 26, 2008 at 01:26:59AM +0300, Manuel Wolfshant wrote:
On 08/26/2008 01:16 AM, Richard W.M. Jones wrote:
On Tue, Aug 26, 2008 at 12:10:14AM +0400, Peter Lemenkov wrote:
Seriously speaking, the main difficulty in maintaining packages, is the total absence of feedback from users *before* any updates.
Well yes, that is the problem. I'm aware of a number of OCaml / EPEL users. They mainly seem to be people using it to teach university courses ...
Rich.
Maybe you could leave the older ocaml as such and create a new ocaml5 ?
That's another possibility. But I've never seen a working parallel OCaml compiler install. It's definitely not as easy as it is with gcc to do parallel / compat installs ... A question for upstream, I think.
Rich.
-- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
I know we have at least 1 app ( maybe more) that would work a lot better with the newer version, (like it would build). I'll vote for the update.
stahnma
On Mon, Aug 25, 2008 at 11:41:24PM -0500, Michael Stahnke wrote:
On Mon, Aug 25, 2008 at 5:24 PM, Richard W.M. Jones rjones@redhat.com wrote:
That's another possibility. But I've never seen a working parallel OCaml compiler install. It's definitely not as easy as it is with gcc to do parallel / compat installs ... A question for upstream, I think.
[...]
So I asked upstream and the situation is quite complicated. Basically there are two possible ways to do this:
(1) We could have a separate subdirectory, like this:
/usr/bin/* for the default compiler /usr/libexec/ocaml-3.10.2/* for the non-default compiler
Users would need to set the $PATH before compiling. This solution looks like it will suck a lot.
(2) We could rename the compiler binaries, like:
/usr/bin/ocamlc /usr/bin/ocamlopt (etc. -- there are about 20 binaries that need renaming) /usr/bin/ocamlc-3.10.2 /usr/bin/ocamlopt-3.10.2 (etc.)
Users would need to modify their build scripts to pick the correct compiler. This solution also sucks, and is even more error-prone than (1).
I know we have at least 1 app ( maybe more) that would work a lot better with the newer version, (like it would build). I'll vote for the update.
Out of interest, what is the app?
Rich.
Richard W.M. Jones wrote:
On Mon, Aug 25, 2008 at 11:41:24PM -0500, Michael Stahnke wrote:
On Mon, Aug 25, 2008 at 5:24 PM, Richard W.M. Jones rjones@redhat.com wrote:
That's another possibility. But I've never seen a working parallel OCaml compiler install. It's definitely not as easy as it is with gcc to do parallel / compat installs ... A question for upstream, I think.
[...]
So I asked upstream and the situation is quite complicated. Basically there are two possible ways to do this:
(1) We could have a separate subdirectory, like this:
/usr/bin/* for the default compiler /usr/libexec/ocaml-3.10.2/* for the non-default compiler
Users would need to set the $PATH before compiling. This solution looks like it will suck a lot.
(2) We could rename the compiler binaries, like:
/usr/bin/ocamlc /usr/bin/ocamlopt (etc. -- there are about 20 binaries that need renaming) /usr/bin/ocamlc-3.10.2 /usr/bin/ocamlopt-3.10.2 (etc.)
Users would need to modify their build scripts to pick the correct compiler. This solution also sucks, and is even more error-prone than (1).
How about installing a package with /usr/bin/ocamlc -3.09.3, /usr/bin/ocamlopt-3.09.3 , etc, another one with /usr/bin/ocamlc-3.10.2, /usr/bin/ocamlopt-3.10.2, etc. and usin alternatives to switch among the two by doing
ln -s /usr/bin/ocamlc -3.09.3 /usr/bin/ocamlc (and so on) or ln -s /usr/bin/ocamlc-3.10.2 /usr/bin/ocamlc
?
I know we have at least 1 app ( maybe more) that would work a lot better with the newer version, (like it would build). I'll vote for the update.
Out of interest, what is the app?
Rich.
On Tue, Aug 26, 2008 at 03:41:12PM +0300, Manuel Wolfshant wrote:
How about installing a package with /usr/bin/ocamlc -3.09.3, /usr/bin/ocamlopt-3.09.3 , etc, another one with /usr/bin/ocamlc-3.10.2, /usr/bin/ocamlopt-3.10.2, etc. and usin alternatives to switch among the two by doing
Yes, alternatives is an, erm, alternative. But don't forget it's not just the base packages, but the stdlib directory, and piles of external libraries (see my .signature), some of which have binaries that depend on the compiler version, particularly ocamlfind. It's do-able but a zoomungous amount of work for not a lot of benefit.
Rich.
Manuel Wolfshant wrote:
Richard W.M. Jones wrote:
On Mon, Aug 25, 2008 at 11:41:24PM -0500, Michael Stahnke wrote:
On Mon, Aug 25, 2008 at 5:24 PM, Richard W.M. Jones rjones@redhat.com wrote:
That's another possibility. But I've never seen a working parallel OCaml compiler install. It's definitely not as easy as it is with gcc to do parallel / compat installs ... A question for upstream, I think.
[...]
So I asked upstream and the situation is quite complicated. Basically there are two possible ways to do this:
(1) We could have a separate subdirectory, like this:
/usr/bin/* for the default compiler /usr/libexec/ocaml-3.10.2/* for the non-default compiler
Users would need to set the $PATH before compiling. This solution looks like it will suck a lot.
(2) We could rename the compiler binaries, like:
/usr/bin/ocamlc /usr/bin/ocamlopt (etc. -- there are about 20 binaries that need renaming) /usr/bin/ocamlc-3.10.2 /usr/bin/ocamlopt-3.10.2 (etc.)
Users would need to modify their build scripts to pick the correct compiler. This solution also sucks, and is even more error-prone than (1).
How about installing a package with /usr/bin/ocamlc -3.09.3, /usr/bin/ocamlopt-3.09.3 , etc, another one with /usr/bin/ocamlc-3.10.2, /usr/bin/ocamlopt-3.10.2, etc. and usin alternatives to switch among the two by doing
This is not really alternatives use case. alternatives is run by the system administrator. Builds are run by a user.
-Toshio
epel-devel@lists.fedoraproject.org
-
Manuel Wolfshant -
Michael Stahnke -
Peter Lemenkov -
Richard W.M. Jones -
Toshio Kuratomi