On Wed, Jun 22, 2022 at 5:32 AM Richard W.M. Jones <rjones(a)redhat.com> wrote:
Annoyingly now that I've done the OCaml rebuild, I discovered
that the
version of Dune that we're shipping is quite old. Fedora Rawhide
ships 2.9.3, latest upstream is 3.3.1.
https://bugzilla.redhat.com/show_bug.cgi?id=2002676
This wouldn't necessarily matter, but I found a new package that
depends on 3.x:
https://bugzilla.redhat.com/show_bug.cgi?id=2099754
Well, it _may_ work with 2.9 (after hacking the dune-project file) but
it fails a bit later because of some missing dependencies so I'm
not entirely sure.
Anyhow, I wonder if there's a reason why we're sticking with dune 2.9,
or if I can upgrade it?
I've actually had an update to dune 3.x waiting in the wings for some
time. You can see it here:
https://copr.fedorainfracloud.org/coprs/jjames/Infer/. (This COPR
repo needs a lot of updating due to the recent OCaml mass rebuild.
I'll try to get to that in the next few days.)
Things to be aware of:
1. There is a new dependency, ocaml-pp. Like ocaml-csexp, it has to
be hacked up to be built without dune, since we need to build dune
with it. Gotta love these circular dependencies.
2. Speaking of circular dependencies, dune 3.x has a new module,
dune-rpc-lwt, that depends on lwt. And, of course, lwt transitively
depends on dune. Nothing in Fedora currently needs dune-rpc-lwt, so
my inclination is to patch it out for now and deal with it later if
such a dependency appears.
3. Dune has several modules that we currently bundle together in
ocaml-dune-devel. I'm starting to see dependencies arise on
individual modules. It may be worth our while to break at least some
of them out into separate packages. In particular, there are lots of
dependencies on dune-configurator, and I am starting to see some on
dune-build-info as well.
4. Dune 3.x removes some old dune 1.x compatibility code. This breaks
alt-ergo, but I have a patch to work around the issue.
I'll attach the spec file and patch I have been experimenting with. I
think this spec file takes #3 too far; it breaks *every* module out
into an RPM package, which is probably overkill.
--
Jerry James
http://www.jamezone.org/