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.