[Fedora-packaging] OCaml library packaging - no-arch for non-devel?

[Richard W.M. Jones]

On Thu, Aug 07, 2008 at 06:41:11PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 07, 2008 at 01:33:30PM -0400, Alan Dunn wrote:
> > Does anyone know whether OCaml library main packages (non-devel
> > packages) should be packaged as no-arch, since they only contain
> > bytecode files, which should be architecture independent? 
> 
> This is  incorrect. For common architectures, OCaml generates native
> machine code - bytecode is only used as a fallback for archs with no
> native code generator backend.
> 
> virt-top for example is written in OCaml and is clearly arch dependant:
> 
> $ file virt-top
> virt-top: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>    dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

For programs (not libraries) the guidelines are even trickier to write
correctly.  The current policy is that we should package "best
possible binaries", meaning fast native code ones where possible, and
falling back to bytecode binaries where we don't have a code
generator.  So we'd need to make the architecture dependent on that
(which is usually determined at rpmbuild time).

Note: this is only a theoretical problem in Fedora / RHEL / EPEL
because we have native code generators for all platforms, including
all the secondary architectures that I'm aware of (PPC64 was a problem
for a while, but David Woodhouse wrote a PPC64 back-end for the
compiler earlier this year).  For Debian it's a real problem because
they support some seriously obscure architectures.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 60 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora