Kristen Kozak

One idea is to add a new JSON file, such as `preferred-versions.json`, to eventually replace `preferred-versions`. The new file would be at the package level, and it would contain both...

I'm not sure what the use case is for preferred versions, since cabal already prefers the latest, but I thought that the deprecation feature was still useful for marking specific...

> [@grayjay](https://github.com/grayjay) What semantics do we (you?) want for "bad" versions? > > If it's really bad, we can always do `base > The current deprecation is only a "soft...

I opened #1374 for removing preferred versions.

> Isn't this the purpose of `buildable: False`? `buildable: False` means that that specific component shouldn't be built, so I think that it would have the same effect if it...

> No, it won't. `cabal-install`s solver does not backtrack on `buildable: False`. I think that it should at least work when `buildable: False` is at the top level after https://github.com/haskell/cabal/pull/5337.

I think that https://github.com/haskell/cabal/issues/10470#issuecomment-2422208659 explains what happened here. I opened a feature request for looking at other local maxima (#11304), and I'm closing this issue, because I think that the...

I think that this issue is part of #3502. Is it possible to work around the specific issue with `happy` by using `any.happy`, or do you need to only constrain...

@geekosaur Were you able to build the project by adding an `any.happy` constraint, or is there another issue that isn't covered by #3502?

I haven't had a chance to look at the code yet, but, if I remember correctly, #9541 was a followup to #9159. Would it make sense to first update and...