Old result packages shadows the Result modules for newer builds

[paurkedal]

The CI from my latest Caqti PR shows that some packages fail during revdep builds since they require features from the Result module from stdlib which gets shadowed by older releases of the result package due to implicit dependencies. That is, library A depends on B which depends on result and can tolerate an old version, but A assumes it gets the Result module from a newer compiler distribution.

After adding

conflicts: [
  "result" {< "1.5"}
]

to my own package avoids the issue. However, there are other packages having the same issues. The build discovers sihl-core and sihl, but there could be more. A simpler but more pervasive solution may be to add an "ocaml" {< "4.08"} constraints to the old result packages?

[hannesm]

see #19880 - for reasons still unclear to me, this "breaks lockfiles", and somehow those "lockfiles" are important.

In any case, maybe "result" packages should carry the conflict burden, seems to be accepted in the opam-repository "for exceptional cases" (see #22512).

TL;DR: so far the "maintainer" of the result package, and some opam repostory maintainers prefer to carry the burden on your shoulder to add "conflicts with result < 1.5", even if your package does not have a dependency on result.

[avsm]

We will have a window to fix this over the coming months when we roll out the "mainline opam repository only supports OCaml 4.08 or higher", as discussed in https://discuss.ocaml.org/t/raising-the-minimum-tested-version-of-ocaml-to-4-05-or-4-08-from-4-02/12464

This restriction will in turn lift up the floor of result packages such that the conflict will no longer be required, I believe...

[mseri]

Honestly I don't see why not adding the upper bound and relieve the self-inflicted pain of adding a conflict on every other package released. The conflict is now on so many packages that it is almost equivalent to an upper bound, we may as well just to that and forget about it.

We discussed this at the maintainers meeting and there is no objection to send a PR once the CI is a bit freer (now there are tezos and dune, so we will not overload it more)

[mseri]

I suggest we close this for the time being since it does prevent installability of a number of packages (and potentially can be breaking if somebody uses lock files). I will look for a solution for the lower bound checker that takes result into account.