On Thu, Jul 29, 2021 at 01:17:01PM -0600, Jerry James wrote:
On Tue, Jul 27, 2021 at 3:06 PM Richard W.M. Jones
> Some ocamlx dependencies, notably ocamlx(Dynlink) are not very stable
> between rebuilds of OCaml even of the same version. I'm unclear why
> this is exactly, but I am currently rebuilding many ocaml packages
> broken by the Fedora mass rebuild for this exact reason.
I've got packages broken by changed hashes on symbols provided by
compiler-libs. For example, ocaml-ppxlib can't be installed because
I saw these too.
It's interesting that we are only seeing changed hashes on
symbols, not on ocaml(*) symbols. What does that mean?
As a background for others reading this, the hashes come from the
output of ocamlobjinfo, eg:
$ ocamlobjinfo /usr/lib64/ocaml/unix.cma | grep Unix
Unit name: Unix
$ rpm -qR ocaml | grep 'ocaml(Unix)'
ocaml(Unix) = eadecc353e942963afccd09bd1a12192
The hash is computed by the OCaml compiler across some internals. It
seems like at least the bytecode and all the associated metadata like
We never had much of a problem with ocaml() hashes except when the
code actually changed, where the hash is expected to change.
The ocamlx hashes which were added recently are the same, but across
the native code. I'm less clear exactly what is covered - for example
is actual code covered by the hashes?
The ocamlx hashes look a lot less stable. They seem to change based
on environmental factor, like changes in dependent libraries, but I
don't understand exactly why.
> Thoughts on this?
Unless we know why the hashes changed, we don't know if ignoring the
change is safe.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch