file /usr/bin/ocamlbrowser conflicts between attempted installs of
ocaml-labltk-devel-3.11.2-2.el6.i686 and ocaml-labltk-devel-3.11.2-2.el6.x86_64

Aside from multilib being generally a broken hack, do you
have any idea how to fix this, or even what is broken?

It might have something to do with the fact that those files are scripts and not binaries but I'm not rpm expert.

OK those were not quite scripts like bash scripts for example.

file reports:
/usr/bin/camlp4:        a /usr/bin/ocamlrun script text executable

The camlp4 file starts with a shebang and binary content, possibly some sort of byte-code. 

Anyway that's probably confusing rpm when generating multilib packages.

Reassigning to RPM.

Multilib should recognize that these are binaries (which they are,
bytecode binaries) and treat them as such.

Eww. The multilib "conflict resolution" has only ever worked with ELF binaries, rpm doesn't have a clue of anything else having similar properties.

To make ocaml bytecode executables behave simiarly to ELF binaries, we'd need
1) make libmagic to detect ocaml bytecode and the bitness
2) make librpmbuild to add appropriate "color" for them, based on bitness reported by libmagic
3) rebuild all ocaml-packages to get the coloring in place

The other, saner option is to split the packaging to avoid the conflicts to begin with. Is there an actual reason for these packages to be multilib, other than "they put stuff in lib/lib64 so they get considered multilib by mash/whatever composition tool?"

[Note: The conflict is on binaries in /usr/bin]

I compared the two files /usr/bin/camlp4 from F13 i686
and x86_64 RPMs.

First of all, either binary will run on either architecture.
I verified this by copying the binaries between machines
and trying to run them.  These are bytecode, so they are
arch-independent binaries.

Secondly the difference in the content of the files occurs
because the files happen to contain a little bit of
configuration information which differs because of the
location of the OCaml libdir (/usr/lib/ocaml vs /usr/lib64/ocaml)
This change is significant, since running:

  /usr/bin/camlp4 -where

(which shows the location of camlp4 libdir) gives
different results for each binary.

The second point means that in reality these binaries
are arch-dependent.  A program that depended on the output
of `camlp4 -where` would fail if we used the wrong binary.
In this case you cannot substitute one binary for another
(but in the general case of OCaml bytecode you could).

-----

So I see some options here:

(1) Opt out of multilib.  I don't want it, it tends to break
things, and it doesn't make sense for OCaml.  Users of OCaml
would always prefer to use the 64 bit version, because it removes
an annoying limit on string length that the 32 bit version suffers
from.

(2) Move the binaries and replace with a shell script.

I would prefer (1).  I do not know what the shell script would
look like.  How would it know which binary to run?  Where would
the binaries go?

(In reply to comment #7)
> (1) Opt out of multilib.  I don't want it, it tends to break
> things, and it doesn't make sense for OCaml.  Users of OCaml
> would always prefer to use the 64 bit version, because it removes
> an annoying limit on string length that the 32 bit version suffers
> from.


+1 for this option.

If multilib doesn't make sense for OCaml then opting out of it is obviously the right thing to do. In Fedora it can be done by hacking up mash, but dunno what's used for RHEL.

CC'ing releng.

It's easy enough for us to drop the multilib package in the compose as long as no other multilib packages depend on it.  Once we drop the package, we'll just need to make sure that upgrading still works.

I'll go ahead and move this to the releng component.

change checked into distill and should appear in the next compose

# pwd
/mnt/redhat/rel-eng/RHEL6.1-20110210.1/6

# find -name "ocaml*i686*" | grep -v i386


The only 32bit ocaml packages are in the 32bit variants.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0540.html