"multiarch conflicts in ..." bugs
Richard W.M. Jones
rjones at redhat.com
Tue Oct 23 16:56:18 UTC 2007
Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said:
>>> The ocamlrun scripts also look like binary (arch dependent?) stuff
>>> so it is a logical that there is conflict. It certainly requires
>>> something to be done at the rpm level, but I am far from being an expert
>>> on those issues.
>> The files which begin with #!/usr/bin/ocamlrun are bytecode files. Even
>> though it's called "bytecode" it isn't portable between architectures. It's
>> not like Java bytecode. So consider these to be like binaries too.
>
> rpm only handles resolving conflicts between 32 and 64-bit ELF files - anything
> else is displayed to the user as a conflict. These bytecode files would
> fall into that category.
Aha. Is there any flag or setting to change this?
Also it still seems to report conflicts with the ELF binaries. If you
want to take a look at some they are in the links below. They look like
perfectly ordinary ELF binaries to my untrained eye ...
http://annexia.org/tmp/camlp4oof.opt.i386
http://annexia.org/tmp/camlp4oof.opt.x86-64
$ file */usr/bin/camlp4oof.opt
i386/usr/bin/camlp4oof.opt: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
2.6.9, stripped
x86_64/usr/bin/camlp4oof.opt: ELF 64-bit LSB executable, x86-64, version
1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
stripped
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/ec9ddafe/attachment.bin>
More information about the fedora-devel-list
mailing list