Bug 239004 - New packaging rules for ocaml and friends
New packaging rules for ocaml and friends
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: ocaml (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gérard Milmeister
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-04 09:10 EDT by Gérard Milmeister
Modified: 2008-04-04 06:04 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 06:04:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kevin: fedora‑cvs+


Attachments (Terms of Use)
find-requires script for ocaml (2.11 KB, text/plain)
2007-05-28 07:09 EDT, Richard W.M. Jones
no flags Details
find-provides script for ocaml (1.83 KB, text/plain)
2007-05-28 07:13 EDT, Richard W.M. Jones
no flags Details
ocaml-find-requires.sh (2.24 KB, application/x-sh)
2007-06-11 11:37 EDT, Richard W.M. Jones
no flags Details
ocaml-find-provides.sh (1.90 KB, application/x-sh)
2007-06-11 11:38 EDT, Richard W.M. Jones
no flags Details

  None (edit)
Description Gérard Milmeister 2007-05-04 09:10:53 EDT
Packaging for rules ocaml and related packages needs to be revised.
The draft is at http://fedoraproject.org/wiki/PackagingDrafts/OCaml.
Comment 1 Richard W.M. Jones 2007-05-04 09:31:37 EDT
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/...
Comment 2 Gérard Milmeister 2007-05-04 09:40:29 EDT
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.
Comment 3 Richard W.M. Jones 2007-05-04 10:32:53 EDT
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?
Comment 4 Richard W.M. Jones 2007-05-28 07:09:38 EDT
Created attachment 155537 [details]
find-requires script for ocaml
Comment 5 Richard W.M. Jones 2007-05-28 07:13:58 EDT
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 )
Comment 6 Richard W.M. Jones 2007-05-28 07:15:22 EDT
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.
Comment 7 Gérard Milmeister 2007-06-01 14:22:30 EDT
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.
Comment 8 Richard W.M. Jones 2007-06-02 10:32:29 EDT
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.
Comment 9 Gérard Milmeister 2007-06-02 13:40:24 EDT
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.
Comment 10 Richard W.M. Jones 2007-06-03 08:01:40 EDT
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
Comment 11 Richard W.M. Jones 2007-06-05 13:08:38 EDT
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.
Comment 12 Gérard Milmeister 2007-06-05 13:30:54 EDT
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.
Comment 13 Gérard Milmeister 2007-06-09 08:55:10 EDT
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.
Comment 14 Marcel Kyas 2007-06-10 19:33:36 EDT
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.
Comment 15 Nigel Jones 2007-06-10 21:18:26 EDT
(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?
Comment 16 Richard W.M. Jones 2007-06-11 10:24:11 EDT
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.
Comment 17 Richard W.M. Jones 2007-06-11 11:36:28 EDT
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.
Comment 18 Richard W.M. Jones 2007-06-11 11:37:43 EDT
Created attachment 156725 [details]
ocaml-find-requires.sh

Includes Gerard's '-f' option, and changes the dependencies to look like
ocaml(Module)=Hash.
Comment 19 Richard W.M. Jones 2007-06-11 11:38:18 EDT
Created attachment 156727 [details]
ocaml-find-provides.sh

Includes Gerard's '-f' option, and changes the dependencies to look like
ocaml(Module)=Hash.
Comment 20 Gérard Milmeister 2007-06-11 12:21:21 EDT
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?
Comment 21 Marcel Kyas 2007-06-11 12:24:45 EDT
(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.
Comment 22 Nigel Jones 2007-06-11 18:54:45 EDT
(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.
Comment 23 Gérard Milmeister 2007-06-12 12:18:47 EDT
I build the packages on FC6, because that's the release I currently. It does not
necessarily mean that FC6 will see the updates.
Comment 24 Richard W.M. Jones 2007-06-12 13:32:50 EDT
Just a note to say that the guidelines as they stand were
just approved by the Fedora Packaging Committee.
Comment 25 Richard W.M. Jones 2007-07-02 05:31:45 EDT
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.
Comment 26 Gérard Milmeister 2007-07-02 07:42:09 EDT
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?
Comment 27 Nigel Jones 2007-07-02 07:50:54 EDT
(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).
Comment 28 Richard W.M. Jones 2007-07-02 10:59:09 EDT
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/
Comment 29 Gérard Milmeister 2007-08-20 14:23:31 EDT
Package Change Request
======================
Package Name: ocaml
Updated Fedora Owners: gemi@bluewin.ch,rjones@redhat.com

Richard W.M. Jones (rjones@redhat.com) is new co-mainntainer
of ocaml package.
Comment 30 Kevin Fenzi 2007-08-20 18:58:08 EDT
Note that cvsrequests should now use Fedora Account System names and not email. 

cvs done. 
Comment 31 Bug Zapper 2008-04-03 20:29:42 EDT
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.
Comment 32 Richard W.M. Jones 2008-04-04 06:04:36 EDT
I'm closing this bug - it refers to an older version of the guidelines
which have since been superseded.

Note You need to log in before you can comment on or make changes to this bug.