Bug 658039
| Summary: | File conflicts between ocaml multilib packages in Optional repo | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Alexander Todorov <atodorov> |
| Component: | releng | Assignee: | Dennis Gregorovic <dgregor> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0 | CC: | dgregor, dmach, jstodola, mbanas, notting, riek, rjones |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 644778 | Environment: | |
| Last Closed: | 2011-05-19 12:55:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 644778 | ||
|
Description
Alexander Todorov
2010-11-29 08:27:28 UTC
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 |