OCaml dependencies encode a MD5 hash across the code in the library. eg:
$ ocamlobjinfo /usr/lib64/ocaml/unix.cma | grep Unix Unit name: Unix e6d191b089c68976347fa6524bb28048 Unix
This is encoded into the Fedora dependency, which is necessary because the OCaml compiler checks the hash and will complain (fail to compile code) if the hash between libraries is not in agreement:
$ rpm -q --provides ocaml | grep 'ocaml(Unix)' ocaml(Unix) = e6d191b089c68976347fa6524bb28048
Note this hash applies to OCaml bytecode libraries, which we don't really use in Fedora, but it was convenient to encode this since it doesn't change except if the source code of the library changes.
So far so good ...
However Fedora recently-ish started also generating a hash for native code OCaml libraries. The change was actually made in RPM here:
https://github.com/rpm-software-management/rpm/issues/913
In theory these hashes are also supposed to be stable - eg. a simple rebuild of the package should not change the hash. Unfortunately for some reason that I don't understand they were changed in the mass rebuild. eg. compare ocamlx(Dynlink) between:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=23061389 (before) https://koji.fedoraproject.org/koji/rpminfo?rpmID=24866739 (after rebuild)
Notice that ocaml(Dynlink) (bytecode) is the same, but ocamlx(Dynlink) (native code) changed.
I tried to reproduce this locally, by recompiling ocaml and changing the release number, upgrading gcc, and a few other things, but I couldn't get the dependencies to change at all.
So ... I don't know.
It's a bit of a mess at the moment, and some, possibly many, ocaml-* packages in Rawhide may be uninstallable.
We're expecting that ocaml 4.12.0 will be released very soon - perhaps as soon as later this week - and I will do a mass rebuild of all the OCaml packages which will as a side effect fix this.
In the meantime I will rebuild packages on demand if people encounter problems (in fact, already started that, see https://bugzilla.redhat.com/show_bug.cgi?id=1923853)
Rich.
On Tue, Feb 2, 2021 at 4:39 AM Richard W.M. Jones rjones@redhat.com wrote:
We're expecting that ocaml 4.12.0 will be released very soon - perhaps as soon as later this week - and I will do a mass rebuild of all the OCaml packages which will as a side effect fix this.
Thanks for handling the rebuilds. I want to note that there be a few dragons lurking in wait for the ocaml 4.12.0 release. I maintain some packages that need to be updated for 4.12.0. The problematic one is ocaml-ppxlib. It is currently on version 0.15.0. The latest upstream version is 0.21.0. All versions > 0.15.0 require ocaml-migrate-parsetree >= 2.0. The 2.x ocaml-migrate-parsetree versions break ocaml-ppx-tools-versioned. There is ongoing effort to move all ocaml-ppx-tools-versioned consumers over to ocaml-ppxlib, but it isn't quite done. To avoid breaking Fedora packages, this is what needs to be done, in approximate package build order:
- ocaml-migrate-parsetree: 1.8.0 -> 2.1.0 - ocaml-tyxml: apply this pull request to switch to ppxlib: https://github.com/ocsigen/tyxml/pull/271 - ocaml-base: 0.14.0 -> 0.14.1 - ocaml-lwt: 5.3.0 -> 5.4.0 - ocaml-bisect-ppx: apply this pull request to switch to ppxlib: https://github.com/aantron/bisect_ppx/pull/327 - ocaml-ppx-deriving: 5.1 -> 5.3 - ocaml-ppxlib: 0.15.0 -> 0.21.0 - ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2 - ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1 - ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2 - ocaml-ppx-optcomp: 0.14.0 -> 0.14.1 - ocaml-sedlex: 2.2 -> 2.3 - Retire ocaml-ppx-tools-versioned
There may be more breakage waiting to happen. I have not done test builds for any of the above yet, because I've been waiting for the ocaml-tyxml and ocaml-bisect-ppx situations to settle out. If they don't release versions compatible with ocaml 4.12.0 by the time the latter is released, we'll either have to apply those pull requests as they are now, or delay introducing ocaml 4.12.0, or leave some of the above packages in a broken state.
On Tue, Feb 02, 2021 at 09:08:37AM -0700, Jerry James wrote:
On Tue, Feb 2, 2021 at 4:39 AM Richard W.M. Jones rjones@redhat.com wrote:
We're expecting that ocaml 4.12.0 will be released very soon - perhaps as soon as later this week - and I will do a mass rebuild of all the OCaml packages which will as a side effect fix this.
Thanks for handling the rebuilds. I want to note that there be a few dragons lurking in wait for the ocaml 4.12.0 release. I maintain some packages that need to be updated for 4.12.0. The problematic one is ocaml-ppxlib. It is currently on version 0.15.0. The latest upstream version is 0.21.0. All versions > 0.15.0 require ocaml-migrate-parsetree >= 2.0. The 2.x ocaml-migrate-parsetree versions break ocaml-ppx-tools-versioned. There is ongoing effort to move all ocaml-ppx-tools-versioned consumers over to ocaml-ppxlib, but it isn't quite done. To avoid breaking Fedora packages, this is what needs to be done, in approximate package build order:
- ocaml-migrate-parsetree: 1.8.0 -> 2.1.0
- ocaml-tyxml: apply this pull request to switch to ppxlib:
https://github.com/ocsigen/tyxml/pull/271
- ocaml-base: 0.14.0 -> 0.14.1
- ocaml-lwt: 5.3.0 -> 5.4.0
- ocaml-bisect-ppx: apply this pull request to switch to ppxlib:
https://github.com/aantron/bisect_ppx/pull/327
- ocaml-ppx-deriving: 5.1 -> 5.3
- ocaml-ppxlib: 0.15.0 -> 0.21.0
- ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2
- ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1
- ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2
- ocaml-ppx-optcomp: 0.14.0 -> 0.14.1
- ocaml-sedlex: 2.2 -> 2.3
- Retire ocaml-ppx-tools-versioned
There may be more breakage waiting to happen. I have not done test builds for any of the above yet, because I've been waiting for the ocaml-tyxml and ocaml-bisect-ppx situations to settle out. If they don't release versions compatible with ocaml 4.12.0 by the time the latter is released, we'll either have to apply those pull requests as they are now, or delay introducing ocaml 4.12.0, or leave some of the above packages in a broken state.
This looks do-able TBH, although some work.
I talked to octachron today and he said we can expect OCaml 4.12 this week or the next.
I have blocked out a couple of days to deal with this.
Rich.
On Tue, Feb 2, 2021 at 12:53 PM Richard W.M. Jones rjones@redhat.com wrote:
This looks do-able TBH, although some work.
I talked to octachron today and he said we can expect OCaml 4.12 this week or the next.
I have blocked out a couple of days to deal with this.
Okay. I'm willing to help deal with breakage, too.
Since the OCaml 4.12.0 release is near, I thought I would report on a few changes from my previous message.
On Tue, Feb 2, 2021 at 9:08 AM Jerry James loganjerry@gmail.com wrote:
Thanks for handling the rebuilds. I want to note that there be a few dragons lurking in wait for the ocaml 4.12.0 release. I maintain some packages that need to be updated for 4.12.0. The problematic one is ocaml-ppxlib. It is currently on version 0.15.0. The latest upstream version is 0.21.0. All versions > 0.15.0 require ocaml-migrate-parsetree >= 2.0. The 2.x ocaml-migrate-parsetree versions break ocaml-ppx-tools-versioned. There is ongoing effort to move all ocaml-ppx-tools-versioned consumers over to ocaml-ppxlib, but it isn't quite done. To avoid breaking Fedora packages, this is what needs to be done, in approximate package build order:
Due to some upstream activity, this is what the list looks like now.
- ocaml-base: 0.14.0 -> 0.14.1 - ocaml-migrate-parsetree: 1.8.0 -> 2.1.0 - ocaml-ppxlib: 0.15.0 -> 0.22.0 - ocaml-bisect-ppx: 2.5.0 -> 2.6.0 - ocaml-tyxml: apply this pull request to switch to ppxlib: https://github.com/ocsigen/tyxml/pull/271 - ocaml-lwt: 5.3.0 -> 5.4.0 - ocaml-ppx-deriving: 5.1 -> 5.2.1 - ocaml-ppx-optcomp: 0.14.0 -> 0.14.1 - ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2 - ocaml-sedlex: 2.2 -> 2.3 - ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1 - ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2 - Retire ocaml-ppx-tools-versioned
I have done some test builds to flush out problems. The ocaml-tyxml pull request cannot be applied as is. First, it doesn't apply cleanly due to commits made after the 4.4.0 release. Second, it doesn't work due to changes made to ppxlib after the pull request was made. I've modified the pull request into a patch that fixes both issues. I am concerned that that pull request has not been updated since last July.
The ocaml-lwt 5.4.0 release adds a dependency on the "luv" library, which we do not have in Fedora. Getting it means adding a handful of new ocaml packages, namely:
- bigarray-compat: https://bugzilla.redhat.com/show_bug.cgi?id=1927441 - integers: https://bugzilla.redhat.com/show_bug.cgi?id=1927442 - ctypes: https://bugzilla.redhat.com/show_bug.cgi?id=1927443 - luv: https://bugzilla.redhat.com/show_bug.cgi?id=1927444
Also, since ocaml-ppxlib is becoming a dependency of ocaml-txyml, ocaml-ppxlib and all of its dependencies will become transitive dependencies of ocaml-odoc, which means we cannot build documentation for those packages with odoc without introducing circularities. I'll add "%bcond_with doc" or something similar to handle this, unless someone has a better idea.
Richard, what's the best way to handle all of this? I can open pull requests on all of the above packages, so you only have to merge them before starting the ocaml 4.12 builds. Or, since I am the primary maintainer for most of them, I can simply push to git when you say you are ready to start. Let me know what works best for you. -- Jerry James http://www.jamezone.org/