On 5 Mar 2026, at 6:21 pm, Henning Thielemann wrote:

The use_crypton flag is declared to be manual. I think this is the problem, it should be automatic.

Yes, that's one of the potential obstacles, but making automatic does not help. The solver does not see the conflict, even if `tsl` declares `conflicts: cryptonite`, and the flag is automatic. I am sure we could convince Olivier to make it automatic, if that would help. -- Viktor.

On Thu, Mar 05, 2026 at 08:44:25AM +0100, Henning Thielemann wrote:

...

Yes, that's one of the potential obstacles, but making automatic does not help. The solver does not see the conflict, even if `tsl` declares `conflicts: cryptonite`, and the flag is automatic.

What is `conflicts: cryptonite`? A Cabal package description field? I do not see it in Cabal-3.16 docs.

AI hallucination apparently. I was on a plane with spotty Wifi, and tried to make to with bad advice from Gemini. So it seems there isn't any practical way to express that `tls` **requires** the `use_crypton` flag in `mlkem` not only in its own build, but also when built as a dependency of other packages. :-( What is the correct way out of this bind? -- Viktor. 🇺🇦 Слава Україні!

On Thu, Mar 05, 2026 at 11:31:17AM +0100, Henning Thielemann via ghc-devs wrote:

...

AI hallucination apparently. I was on a plane with spotty Wifi, and tried to make to with bad advice from Gemini. So it seems there isn't any practical way to express that `tls` **requires** the `use_crypton` flag in `mlkem` not only in its own build, but also when built as a dependency of other packages. :-(

Ok, I see why the automatic flag does not solve the problem: In terms of package dependencies there is no conflict for Cabal between `crypton` and `cryptonite` and thus it chooses both of them. So, Cabal would actually need something like a "conflicts" field in the package description.

Yes, the Gemini AI was hallucinating its existence, but perhaps that's not entirely a bad idea for a new feature. -- Viktor. 🇺🇦 Слава Україні!

A good rule of thumb for automatic flag selection is to make "constraints" induced on dependency solver disjoint, which would make flag values a function of install plan. E.g. if flag(old-base)   build-depends: base <4 else   build-depends: base >=4 Given an install plan, I can tell what value the `old-base` would been assigned. That is deterministic function. I don't see how you would translate `conflicts` to package dependency problem constraint. Importantly: having `crypton` and `cryptonite` in different parts of install plan is completely fine. No individual package (author) should be able dictate that you cannot use some other package in the same project. So, the fake-depends https://github.com/haskell/cabal/issues/11053 I linked **adds dependency to be satisfied** (just not exposed), while unrestrained `constraints` proposed in that issue later would be too powerful. - Oleg On 3/6/26 04:12, Viktor Dukhovni via ghc-devs wrote:

On Thu, Mar 05, 2026 at 11:31:17AM +0100, Henning Thielemann via ghc-devs wrote:

...

...

AI hallucination apparently. I was on a plane with spotty Wifi, and tried to make to with bad advice from Gemini. So it seems there isn't any practical way to express that `tls` **requires** the `use_crypton` flag in `mlkem` not only in its own build, but also when built as a dependency of other packages. :-( Ok, I see why the automatic flag does not solve the problem: In terms of package dependencies there is no conflict for Cabal between `crypton` and `cryptonite` and thus it chooses both of them. So, Cabal would actually need something like a "conflicts" field in the package description. Yes, the Gemini AI was hallucinating its existence, but perhaps that's not entirely a bad idea for a new feature.

On Thu, 5 Mar 2026, Adam Gundry wrote:

On 05/03/2026 05:54, Viktor Dukhovni wrote:

...

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

The general principle (albeit one that is not necessarily widely understood or well advertised) is that package APIs should not depend on flag assignments, for precisely the reason you outline:

I think that condition is satisfied here: The API of tls is independent from whether mlkem calls crypton or cryponite. So in principle things should work if `tls` uses `crypton`, and `mlkem` uses `cryptonite`, as Cabal might choose as default.

So either forking `mlkem` or a major version bump seem to be the sensible choices. I hope Olivier can be convinced to go the version bump route.

I can access codeberg.org today: - https://codeberg.org/ocheron/hs-mlkem/issues/4 - https://codeberg.org/ocheron/hs-mlkem/issues/5 I should resolve an issue of "crypton" from Oliver in #4. Also, we are trying to remove "basement" and "memory" from our libraries including "mlkem" (in #5). For more information, please read: - https://github.com/kazu-yamamoto/crypton/pull/67 --Kazu