Bug 239004

Should we have a version number in the pathnames to binaries, in particular
libraries?

There is basically no concept of stable ABIs in OCaml (see this thread:
http://lists.debian.org/debian-ocaml-maint/2005/01/threads.html#00042 ) so if
you are unlucky enough to be in possession of a binary-only library, then you
need to have a precisely corresponding version of OCaml + any other libraries it
may depend upon.  In theory it seems even a bugfix which didn't affect the
external signature of a library could cause ABI incompatibility.

If we had it, it would allow multiple versions of OCaml to be installed in
parallel - potentially fixing the above problem.

If my reading of that thread is right, then we'd need to have not just the OCaml
version in the path, but even the RPM release number - eg.
/usr/lib/ocaml/3.09.1-25/...

The problem is, of course, that we then need compatibility packages.
For example compat-ocaml-3.09.3. But since every version (even bugfix) changes
ABI, we would need a compat package for every past version! The names must
contain the version number, in order that different compatibility version can be
installed: compat-ocaml3.09.2, compat-ocaml3.09.1, etc... Currently, when a new
version of ocaml is released, all dependent packages need to be rebuilt. It
would be helpful, if automatic rebuild notification for dependents were available.

I took at look at the description of compat-* packages in the Fedora guide
(http://docs.fedoraproject.org/drafts/rpm-guide-en/ch18s02.html ) and I don't
understand if those are necessary.  Can we not just keep the old RPMs around?

Anyway, the issue goes away if we don't bother with a pretense of ABI
compatibility.  But I wonder why the Debian folks do this?

Created attachment 155537 [details]
find-requires script for ocaml

Created attachment 155538 [details]
find-provides script for ocaml

The two scripts attached are replacements for find-requires and find-provides
which pull the requirements from the .cmi, .cmo and .cma files of a library.

In normal use, add the following to the spec file:

%define _use_internal_dependency_generator 0
%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
%define __find_provides /usr/lib/rpm/ocaml-find-provides.sh

For ocaml.spec add:

Source4:	ocaml-find-requires.sh
Source5:	ocaml-find-provides.sh

%define _use_internal_dependency_generator 0
%define __find_requires %{SOURCE4} -i Asttypes -i Outcometree -c
%define __find_provides %{SOURCE5}

(The extra flags are needed to stop ocaml depending on itself and to ignore
some problematic modules.  For more info see:
http://groups.google.com/group/fa.caml/msg/f2c3e9e8cfa628b3 )

Sorry, ocaml.spec also needs to distribute the scripts and ocamlobjinfo:

In the %install section:

cp tools/objinfo $RPM_BUILD_ROOT%{_bindir}/ocamlobjinfo
mkdir -p $RPM_BUILD_ROOT/usr/lib/rpm/
cp %{SOURCE4} $RPM_BUILD_ROOT/usr/lib/rpm/
cp %{SOURCE5} $RPM_BUILD_ROOT/usr/lib/rpm/

and add the corresponding files in %files too.

Since 3.10 is out it time to make a new release (which also contains Richard's
scripts) and maybe we should decide if some restructuring is necessary.
* Can we leave the package as it is, or split of some parts into a -devel package?
* Should sub packages be prefixed with ocaml- ?
  (ocaml-labltk, ocaml-camlp4)
* How is support for ppc64 going?

Feedback welcome.

I've been holding off on OCaml 3.10 because the camlp4 changes aren't integrated
everywhere upstream yet (cduce is a particular culprit apparently).

But if you want to make a 3.10 release, then once it makes its way into Fedora I
will rebuild all my packages against it and chase upstream where there are
problems.  So don't let me stop you :-)

My personal preference would be to have all OCaml packages called ocaml-*
(except for standalone programs like freetennis and cduce).  But that's just
because I like to be able to do 'rpm -qa | grep ^ocaml' to find out what I'm using.

ocaml-devel would be nice.

No idea about ppc64 support.  I'd like to help out, but until someone buys me a
PS3 (or whatever it is that has ppc64) it's not likely I can do very much.

I have another idea for splitting:
Instead of ocaml and ocaml-devel, there would be "ocaml-runtime" that contains
the runtime libraries as well as ocamlrun, and "ocaml" that contains the ocaml
interpreter, the compilers and the development libraries.

If you want more ideas for how to split, take a look at the Debian packaging
guidelines[1] where they have an insane^Wcomplicated policy to split the
base.  To be fair, their main motivation is to avoid base OCaml depending
on X11 and thus pulling in X11 libs, when really they are only needed for
a few parts which programmers rarely use (Graphics and labltk).

Personally I think Debian's system is overcomplicated, but I guess
removing the dependency on X may be something to consider ...

[1] http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt

From: https://www.redhat.com/archives/fedora-packaging/2007-June/msg00026.html

During my find-requires script, I need to get the exact
name-version-release of the ocaml compiler. Obviously the
compiler knows its name & version, but not its release.

At the moment I'm doing:

  if [ -n "$emit_compiler_version" ]; then
      # Every OCaml program depends on the precise version of the
      # compiler which was used to compile it.
      rpm -q --qf '%{NAME} = %{VERSION}-%{RELEASE}\n' ocaml
  fi

but if calling rpm like this is bad, I'm wondering how to
fix it. Best way I can see to do this is to store the
name-version-release of the compiler in a special file in
the ocaml RPM, something like:

  /usr/lib64/ocaml/fedora-ocaml-release

which would contain something like 3.09.0-3 or whatever, then
the script can be changed to cat this file.

Ok, I will include such a file. When I have a new working package, I will post
them somewhere and you can try it out.

The new package is available at:

http://math.ifi.unizh.ch/fedora/tmp

Notes:
The ocaml-find-requires.sh and ocaml-find-provides.sh are modified
to accept an additional option -f which requires the absolute path
of the ocamlobjinfo program. This is necessary since ocamlobjinfo
is not yet installed during building of the ocaml package. I also
build the native version of ocamlobjinfo, so that it works correctly
from the $RPM_BUILD_ROOT installation.
I needed to add the symbol "Cmo_format" to the excludes of find_requires. 
In ocaml-find-requires.sh I changed
    rpm -q --qf '%{NAME} = %{VERSION}-%{RELEASE}\n' ocaml
to
    echo "ocaml = `cat /usr/lib*/ocaml/fedora-ocaml-release`"
Please check that the requires and provides are ok and that files are in
the packages they belong to.
There is are problem (due to a bug in rpm, I think), that on removal
of all ocaml packages, some of the directory structure still remains.

The ocaml has runtime a dependency on gcc, ncurses-devel, and all devel packages
ocaml currently buildrequires, because ocamlopt and ocamlopt.opt compile to C
and call gcc to obtain the native executable.  This often means that the
developement files are also needed.

(In reply to comment #13)
> The new package is available at:
> 
> http://math.ifi.unizh.ch/fedora/tmp
I'm not totally sure if a major bump is appropriate for FC6 (and FC5), but I
think it'd be particually useful if we could commit the spec file and tarball to
devel/ and once that's perfected move it to F-7

There are some changes that could be made, I'll have a look when I get home tonight.

We should hold off any builds until Packaging Committee has approved the draft
though.  (I'll also note, that I believe the find-provides scripts will be
entered into the rpm rpm's once PackCom is happy)

Thoughts?

Marcel Kyas:

ocamlopt doesn't compile to C, but it does call gcc purely as
a linker in order to link together the native code modules
(*.o files) that it builds.

Nigel / Gerard:

I will have a look at how hard it will be to move all the
packages to 3.10.  As you know camlp4 has completely changed
and some upstream packages haven't caught up.

Rich.

Gerard:

My comments on the 3.10 packages that you uploaded:

(1) I'm hoping that ExcludeArch: ppc64 won't be necessary in future.  However to
make this change we'd need to have a lot of conditional %ifarch ppc64, and I
can't see us writing that correctly without actual access to a ppc64 machine.

(2) I get errors about rpaths in the .so files.  I can suppress these by setting
QA_RPATHS=0x0001

(3) Split ocaml/ocaml-runtime looks good.  Split ocaml/ocaml-x11 also looks good.

(4) Do we need a dependency on gcc, as Marcel points out above?  Not sure about
other deps however.

I'll upload my modified ocaml-find-provides.sh and ocaml-find-requires.sh to
this bug (includes your '-f' option, plus the change required by fedora
packaging team to how dependencies are represented).

So basically, it looks fine to me.

Created attachment 156725 [details]
ocaml-find-requires.sh

Includes Gerard's '-f' option, and changes the dependencies to look like
ocaml(Module)=Hash.

Created attachment 156727 [details]
ocaml-find-provides.sh

Includes Gerard's '-f' option, and changes the dependencies to look like
ocaml(Module)=Hash.

Yes, gcc is required and also all the devel files, for example libX11-devel,
etc., at least those in Makefile.config I presume. That would be:
libX11-devel
libgdbm-devel
Anything missing?

(In reply to comment #20)
> Yes, gcc is required and also all the devel files, for example libX11-devel,
> etc., at least those in Makefile.config I presume. That would be:
> libX11-devel
> libgdbm-devel
> Anything missing?

ncurses-devel seems to be missing for building custom runtimes.

(In reply to comment #17)
> Gerard:
> My comments on the 3.10 packages that you uploaded:
> (1) I'm hoping that ExcludeArch: ppc64 won't be necessary in future.  However 
to
> make this change we'd need to have a lot of conditional %ifarch ppc64, and I
> can't see us writing that correctly without actual access to a ppc64 machine.

There is a patch in progress, both myself and David have been working on one 
(but that was for .9.3, so should look at making that for 10.0 now), check back 
on your emails from a month or so ago.

I'm still not sure if a major bump for FC6 is such a good idea though.

I build the packages on FC6, because that's the release I currently. It does not
necessarily mean that FC6 will see the updates.

Just a note to say that the guidelines as they stand were
just approved by the Fedora Packaging Committee.

Is there any chance that ocaml 3.10.0-1 can go into Rawhide?
I've been using it here for nearly a month, and lack of this
package is blocking anything else from moving forwards.

The only thing I have changed is to remove 'ExcludeArch: ppc64'.
Even if it only builds bytecode on ppc64, the other packages
should be able to cope with that.

I have still been waiting for some feedpack. However I can go on an
check the changes into devel and request a build. I hope we also get
the lablgl and lablgtk renamed soon, so that rawhide has a complete
set of new ocaml packages.
BTW, does the spec file build without the 'excludearch ppc64' without
problems on ppc64?

(In reply to comment #25)
> The only thing I have changed is to remove 'ExcludeArch: ppc64'.
> Even if it only builds bytecode on ppc64, the other packages
> should be able to cope with that.

I don't think this is appropriate, I think the ExcludeArch should stick for now.

There would be an expectation (especially as it's related to development) that
one build works exactly the same as a build for another architecture.

I also doubt many ocaml- packages would be able to build against a non
nativecode ocaml.  (I have not had the chance to check, but I could).

Re: ExcludeArch ppc64.

I don't know as I don't have PPC64 to test on.  I'm not bothered
either way.  Would much rather see OCaml 3.10 go into rawhide
as soon as possible.  I have been using gemi's 3.10.0-1 package
extensively in the past few weeks, and there are no problems except
for one upstream segfault bug
(http://groups.google.com/group/fa.caml/msg/b91700d297054004).

> I also doubt many ocaml- packages would be able to build against a non
> nativecode ocaml.  (I have not had the chance to check, but I could).

All my latest packages should build correctly if ocamlopt
is missing.  (Unless I've made mistakes, of course).
http://www.annexia.org/tmp/ocaml/

Package Change Request
======================
Package Name: ocaml
Updated Fedora Owners: gemi,rjones

Richard W.M. Jones (rjones) is new co-mainntainer
of ocaml package.

Note that cvsrequests should now use Fedora Account System names and not email. 

cvs done. 

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

I'm closing this bug - it refers to an older version of the guidelines
which have since been superseded.