Herbert Valerio Riedel

I don't have time to go into details, but I'll quickly say: Having some level of support for package deletion is on the roadmap (we need something like that for...

@23Skidoo Only as an external prototype (which is intended so we can adapt/extend cabal's multi-repo support to properly handle it -- NB: the candidate index violates a few assumptions you...

IIRC we tried to enable this but ran into issues w/ the CDN... maybe it's worth sorting this out once and for all... cc @gbaz

@tambry if this is for the sake of `cabal` clients, would a DNS entry `hackage-ipv6.haskell.org` which points to a IPv6 enabled target help?

@23Skidoo btw, we can avoid paying for the slow-legacy fallback when it's not needed, because we know when TH is needed (we already require `TemplateHaskell` to be declared in `*-extensions`...

Unfortunately we not only missed the boat for GHC 8.4, but most likely also for GHC 8.6 to get supporting features into GHC... as https://phabricator.haskell.org/D3898 got stuck on a decision...

@tolysz unfortunately this is in conflict with the API design layed out in #6 which would provide us with exact control over flushing which is something that streaming frameworks require...

@tolysz the conflict I see (unless I'm wrongly assuming what this PR does): the new API would give you the choice to either flush explicitly (via `compressFlush`) or don't flush...

Well... they do show up on http://matrix.hackage.haskell.org as requiring attention. :-) I'll just add a few `servant < 0.2` and `base` version constraints for those deprecated packages... that'll move them...

@conal, see https://ghc.haskell.org/trac/ghc/wiki/LanguagePragmaHistory I've edited in a `base>=4.7` constraint to the two affected releases: - https://hackage.haskell.org/package/MemoTrie-0.6.3/revisions/ - https://hackage.haskell.org/package/MemoTrie-0.6.4/revisions/ Here's the current overall situation: - http://matrix.hackage.haskell.org/package/MemoTrie