Herbert Valerio Riedel

@conal that depends on what you intend to support. Do you want to support only GHC >= 7.8 in future releases? Or do you want to add some compatibility workaround...

@ddssff could well be that it picked a different install-plan according to the constraints. Older `cabal` versions were more conservative, but `cabal new-build` is more liberal as it doesn't suffer...

@ddssff it's up to you :-) If you don't want to support it, you can simply tweak the meta-data on Hackage (or I can do it), at e.g. https://hackage.haskell.org/package/cabal-debian-4.35.5/cabal-debian.cabal/edit

@ddssff The tested-with field is not interpreted by cabal's solver (it is however interpreted by https://github.com/hvr/multi-ghc-travis/blob/master/make_travis_yml_2.hs if you want to give it a try). You'd rather have to edit the...

It appears that `plugins-1.5.6.0` did address the original issue, however now we're back to square one with GHC 8.2.1 and Cabal-2.0: ``` In order, the following will be built (use...

To be honest, I'm rather sceptical about this proposal being effective at achieving the stated goals. As such, I'm not convinced enough of its merits to support this.

@bennofs btw, wasn't there already some mailing-list discussion about this?

@phadej yeah, the only not-so-nice thing about that is that in `stm` it'd be an orphan

Yeah, this ticket predates the backdoor module by 1 year... so I mostly forgot about this... if anyone wants to take a stab at a PR...? :-)

tbh, I'd like the @haskell/core-libraries-committee to sign off on this. Personally, I'd prefer an unimplementable instance, as otherwise all it takes is one orphan instance hidden somewhere in a popular...