OCaml library packaging - no-arch for non-devel?

[Alan Dunn]

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? It seems
that convention (by looking at the list of available OCaml libraries)
is to make them architecture dependent (that is, just have a version
for each architecture even though there shouldn't be architecture
dependent contents), though rpmlint complains. It seems that Debian's
policy (http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt),
from which one might've been tempted to draw suggestions, is to
include the native code files in the main library package, which is
not done for Fedora. (This also doesn't seem to be addressed in the
Fedora OCaml packaging guidelines either.) Is this something that just
should be done but often isn't, or did I miss something else?

- Alan

[Daniel P. Berrange]

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


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[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

[Richard W.M. Jones]

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? 
For the main package in _libraries_ (not programs, obviously) you're
right.  The only reason we don't do this is that RPM doesn't make it
possible to do :-(

If you can suggest a way to write a spec file so that the main package
is noarch and subpackages are arch-dependent, please let us know.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

[Tom Callaway]

On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote:
>  If you can suggest a way to write a spec file so that the main
> package
>  is noarch and subpackages are arch-dependent, please let us know. 
Not really possible without having the buildsystem do multiple passes
(like kernel), which we really want to avoid.

~spot

[Richard W.M. Jones]

On Thu, Aug 07, 2008 at 02:05:41PM -0400, Tom spot Callaway wrote:
>  On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote:
>  > If you can suggest a way to write a spec file so that the main package
>  > is noarch and subpackages are arch-dependent, please let us know.
>  
>  Not really possible without having the buildsystem do multiple passes
>  (like kernel), which we really want to avoid. 
That's right, I knew there was another reason for this :-)

This all came up when we got the original guidelines approved.  I even
built bytecode packages of some library on x86 & ppc to prove that the
bytecode files really are identical.

One way might be to move all the bytecode files into a subpackage
(which is noarch) and have the main package (which would now be pretty
much empty) 'Require' it.

We don't want to break the ability to do 'yum install ocaml-foo ;
ocaml ; #require "foo"'

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

[Axel Thimm]

On Thu, Aug 07, 2008 at 02:05:41PM -0400, Tom spot Callaway wrote:
>  On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote:
>  > If you can suggest a way to write a spec file so that the main package
>  > is noarch and subpackages are arch-dependent, please let us know.
>  
>  Not really possible without having the buildsystem do multiple passes
>  (like kernel), which we really want to avoid. 
Maybe a feature request for rpm 4.7? E.g. BuildArch per %package?
-- 
Axel.Thimm at ATrpms.net

[Panu Matilainen]

On Fri, 8 Aug 2008, Axel Thimm wrote:

>  On Thu, Aug 07, 2008 at 02:05:41PM -0400, Tom spot Callaway wrote:
> > On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote:
> >> If you can suggest a way to write a spec file so that the main package
> >> is noarch and subpackages are arch-dependent, please let us know.
> >
> > Not really possible without having the buildsystem do multiple passes
> > (like kernel), which we really want to avoid.
>
>  Maybe a feature request for rpm 4.7? E.g. BuildArch per %package? 
No need to file a separate request, this is one of the top 5 often 
requested things and priorized to be done "real soon now".

 	- Panu -