On Wed, Jun 24, 2020 at 12:39:24PM -0600, Jerry James wrote: > This message is mostly for Richard Jones, but I'm sending it to the > list so that others who maintain OCaml packages can weigh in if they > choose. I have BCCed a few of you that are affected by some > suggestions I make below. > > I have spent the last several days doing mock builds to see if I can > safely update all the OCaml packages I maintain to their latest > versions, since some have new versions that are specifically for OCaml > 4.11 compatibility. The following remarks, in no particular order, > stem from that effort. About 4.11, I noticed that alpha #3 was released last week. I'm still waiting for the beta before I do a rebuild however, and I think that's still a few weeks away. > First the good news: I was able to build all the updated versions > successfully, although see below. > > Some of the recently-added packages have boolean dependencies, which I > added at the reviewer's request in order to mimic the version > requirements in the opam files. The ocaml-ppx-custom-printf spec > file, for example, has this: > > BuildRequires: (ocaml-base-devel >= 0.13 and ocaml-base-devel < 0.14) > > It never occurred to me until now to ask if your (Richard's) ocaml > rebuild script can handle such dependencies. Can it? (And I lost the > link to the script. Can you supply it again?) Yeah probably it won't, but I should be able to fix it. The script is: http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary > The utop package has a new version, 2.6.0, that brings OCaml 4.11 > compatibility. However, it requires version 3.1.x of > ocaml-lambda-term, which has a new dependency, mew_vi, that we do not > have in Fedora. The mew_vi module requires mew, which requires trie. > I have submitted review requests and am waiting for somebody to > respond to yesterday's request for review swaps: > https://bugzilla.redhat.com/show_bug.cgi?id=1850263 > https://bugzilla.redhat.com/show_bug.cgi?id=1850264 > https://bugzilla.redhat.com/show_bug.cgi?id=1850265 > > I successfully updated all of the Jane Street packages that are > currently on version 0.13.x to version 0.14.0. However, one of them > is going to be somewhat problematic. The ocaml-ppx-inline-test > package has a new dependency, time_now. The time_now module has 11 > dependencies that we do not already have in Fedora. All 11, and > time_now itself, were on my roadmap for eventual inclusion in Fedora, > but I had not intended to pursue them just yet. I haven't put any of > the 11 up for review yet, although I have written spec files and done > local mock builds for them all. I need to go over them once more and > then I'll put them up for review. If the timeframe to an ocaml 4.11 > build is too short to wait for that, we may have to disable tests for > packages that currently consume ocaml-ppx-inline-test, and leave it in > a broken state until those reviews can be completed. > > I would like to see some updates to other people's packages. For all > of the following, I have the necessary spec file changes ready to show > to the maintainers should they like to see them. > > Updating ocaml-bisect-ppx to its latest version requires updating > ocaml-ppx-tools-versioned to version 5.4.0 or later. > > I suggest that we update to ocaml-ocplib-endian from version 1.0 to > 1.1. It includes fixes for a couple of issues > (https://github.com/OCamlPro/ocplib-endian/issues/20 and > https://github.com/OCamlPro/ocplib-endian/issues/21) that I think we > would like to have resolved. This entails a change to building with > dune. Unfortunately, a new issue makes some tests fail > (https://github.com/OCamlPro/ocplib-endian/issues/18), but I hope to > find a workaround for that soon. > > I suggest an update to ocaml-result from version 1.2 to 1.5. This > version makes Result an alias of Stdlib.Result on recent OCaml > versions. Again, this entails a change to building with dune. > > We could also update ocaml-seq to 0.2.2 just to drop the downstream > patches (this is yet another conversion to building with dune, by the > way), but I don't know that there is any other advantage to updating. > > We could update ocaml-react to version 1.2.1 to drop the downstream > patch. This entails a license change. > > A rebuild seems like a good opportunity to update ocaml-lwt to version > 5.3.0. With this version, a number of spec file simplifications are > possible. > > I've got changes ready to update ocaml-sedlex to version 2.2 AND add a > %check script. > > I've been wondering about uchar and stdlib-shims. We don't need them > in Fedora, but then we don't really need ocaml-result or ocaml-seq > either. Should we add uchar and stdlib-shims, just so we can stop > modifying upstream dune and opam files? That might also benefit > Fedora users who try to build using Fedora's ocaml ecosystem. > > Maybe I should do COPR builds of all this so everybody can easily see > what I'm talking about? I did a total of 63 package builds in mock, > many of them simple rebuilds, so it will take a little time to get > that going. Do we know yet what the timeframe is for an ocaml 4.11 > release? This is all great stuff, and I think it also makes me wonder how we can make OCaml packaging simpler in Fedora. RPM has a new %generate_buildrequires feature which we might utilise (driven from the opam package metadata, I guess?). I would also like to drop the whole ocaml-pkg vs ocaml-pkg-devel split, it's confusing and not necessary. And maybe we could look at some kind of opam2spec scripting, similar to cpanspec. Of course the devil is in the details because unless we can mostly automate packaging, we could end up with something that's even more complicated to deal with the exceptional cases. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
