On Wed, 2007-05-30 at 15:14 +0100, Richard W.M. Jones wrote:
Toshio Kuratomi wrote:
> Thanks, those scripts look good.
So what's the next step? I've added (or in two cases, changed) 14 OCaml
packages which are waiting for another person to review them. You can
get the full list of Bugzillas through this link:
If you, Gérard, Hans, and the other people working on OCaml think the
guidelines are ready we can discuss and vote to include them at next
week's packaging meeting. The committee is meeting at Tuesday at 17:00
UTC for about an hour in #fedora-meeting on freenode IRC. If any of you
can make it to the meeting that would be great as it helps to have
someone familiar with the language there to field any questions that may
I understand that everyone's really busy getting F7 out of the
also that OCaml doesn't interest many people. But anyway to kick things
off, here are some of the things which I think could be problems:
(1) Because of the strict dependencies, users could only upgrade ocaml +
all OCaml libraries they are using in one go.
(2) Also as a consequence of (1), if a major release of OCaml comes out,
all OCaml libraries have to be upgraded at the same time. If, for
example, we move to 3.10, then all libraries upstream must support 3.10.
--> Possible solution to (1) & (2): Put the version number in
the library path, as Debian does. This may allow multiple versions
--> Upstream support (2) is not much of a problem in reality.
Other packages like this (python, perl, ruby) do have versioned
subdirectories so that might be the best way to go. Do upstream build
scripts generally make this easy to do?
(3) OCaml contains a native code compiler, but that compiler
ported to all architectures that Fedora supports. It has a bytecode
compiler which works everywhere (but is interpreted and hence slow). I
haven't been very careful about detecting if native code is supported on
the current architecture.
--> ExcludeArch and/or lots of nasty %ifarch sections in %files.
--> I don't have a non-native arch to test on.
What's missing? ppc64? Is there a possibility of support being added
upstream? I can't think of any other packages/languages that have this
problem offhand. We may need to do something nasty with subpackages and
%ifarch but I'd rather avoid that if possible. I don't know how
possible that is, though.
(4) rpmlint gives a few familiar warnings:
devel-file-in-non-devel-package (about *.cmi files)
Looks like this one is being worked on.
--> A consequence of the above.
--> You can't strip OCaml bytecode binaries because the bytecode
gets stripped too. Arguably that's an upstream bug.
--> Packages which contain no binaries should be in noarch -
fair enough, but I don't know how to do this in the spec file
and keep the subpackages arch-specific.
Yeah -- if one package/subpackage is arch specific then all of the
pieces built from it have to be.
--> The ./configure scripts are often written in OCaml and don't
use the standard autoconf options.
Okay. So this looks like rpmlint sees ./configure as an autoconf
configure script when it really is not.
(5) How does the Fedora build system work? To build a library you
to have the OCaml compiler and all dependent libraries installed
(enforced through BuildRequires) and you'll get out an RPM which only
installs with the precise compiler and library which were installed when
it was compiled. So the only sequence that works is:
# remove all ocaml RPMs
$ rpmbuild -ba ocaml.spec
# install ocaml RPM
$ rpmbuild -ba ocaml-lib1.spec
# install ocaml lib1 RPM
$ rpmbuild -ba ocaml-lib2.spec
# install ocaml lib2 RPM
Every build is a fresh mock buildroot. It includes the packages in the
minimal install plus BuildRequires and their dependencies. The packages
are drawn from the current download repository plus the packages that
have been built recently but not yet made it to the repository. With
the new koji builders (for F7) you have to tell it to do a chainbuild to
guarantee that the recently built package is included in the new build.
Until a better UI is worked out, here's a post on how to do that:
I think that will take care of getting new versions of OCaml through the