<div dir="auto">It seems to mostly be an issue for stack, which wants a fully consistent package set.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019, 12:54 PM Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> writes:<br>
<br>
> The biggest problems are for packages like containers, that are not only<br>
> used by GHC but also exposed to users through the GHC API. These libraries<br>
> aren't part of GHC or base, but pretty much have to move in lock step.<br>
><br>
I'm not sure I understand why this is so. Yes, install plans involving<br>
the GHC library are forced to use the same version of containers that<br>
GHC uses, but I would think that this is not the common case.<br>
<br>
Assuming most people aren't linking against the GHC library then I don't<br>
see the harm in GHC staying a bit behind upstreams like containers.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div>