Dear Cafe and GHC-devs,
I am happy to see that Yamamoto-san (cc:d) (the maintainer of the `tls`
package) is extending it to include support for MLKEM key agreement.
This in turn depends on the `mlkem` library by Olivier Chéron (also
many thanks!).
Now it turns out that for maximum portability, `mlkem` in turn has a build
flag `use_crypton` that selects either `crypton`, or (current default) the
older `cryptonite` library as its dependency. So the dependen graph is:
tls <- mlkem <- if (use_crypton): crypton else: cryptonite
But, at this, point `tls` is crypton-only, and no longer builds with
the older cryptonite equivalents. Therefore `tls` adds
constraints: mlkem +use_crypton
to its `cabal.project` file, which solves the problem for `tls`, but sadly
not for any projects that in turn depend on `tls`. To them the constraints
in the `cabal.project` file of `tls` are effectively invisible.
Since the default flag value in `mlkem` is for now `use_crypton: false`,
each project that wants to use the (work-in-progress) `tls` appears to need to
explictly know that `tls` requires a non-default build of `mlkem`, and must
add the same constraints to its `cabal.project`.
That transitive explicit configuration requirement is not something one can
reasonably ask projects that depend on `tls to have to add.
And of course, more generally, any other such indirect flag-dependent conflict
must not become a burden on all consumers of library B that is only compatible
with a specific variant of library C.
How is this situation supposed to be handled? Is there something in cabal
that can automatically convince the solver to select a setting of the `mlkem`
flag that is compatible with `tls`? Must `mlkem` be forked instead to be two
libraries, one dependent on `cryptonite` and another dependent on `crypton`?
I've been unable to find a satisfactory workaround. Any help appreciated.
--
Viktor.
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
