<br><br><div class="gmail_quote">On Thu, Jul 23, 2009 at 6:42 PM, Trent W. Buck <span dir="ltr"><<a href="mailto:twb@cybersource.com.au">twb@cybersource.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Eric Kow <<a href="mailto:kowey@darcs.net">kowey@darcs.net</a>> writes:<br>
> So we could *still* try to keep the zlib code around, only this time<br>
> agree to get rid of it, when it is a demonstrably an impediment to<br>
> progress.<br>
<br>
</div>Consider the case where a user reports a strange bug that none of us can<br>
reproduce. After weeks of discussion, it finally is discovered that<br>
zlib 0.5.0 was installed on that user's system, so cabal silently picked<br>
-f-zlib. That user was using the internal zlib instead of libHSzlib.<br>
<br>
This actually happened to me -- if I hadn't bothered to configure<br>
--verbose and check the flags, I would be running the internal zlib<br>
right now and not even know it.</blockquote><div><br>Good point. I think we may want to check if cabal has a 'deprecation' warning it can give for certain options or combinations of options. If so, we could use that. I guess we could even implement it as a hook, but if we go to that much trouble we might as well just get rid of this zlib.<br>
<br>Jason</div></div><br>