<p dir="ltr">There's no option which avoid needing to fix all packages on hackage, so each maintainer using this function will be responsible for fixing his packages.</p>
<p dir="ltr">If we fix it in place everyone needs to add CPP to avoid calling the broken version on old versions of directory and use an alternative implementation.</p>
<p dir="ltr">If we make a new function everyone needs to conditionally call the new function or use an alternative implementation.</p>
<br><div class="gmail_quote">On Tue, Jan 6, 2015, 12:38 PM Johan Tibell <<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Who volunteers to fix the breakages in Cabal and add all the needed CPP?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">This seems reasonable, but if we have a deprecation cycle, the old name should (temporarily) be a synonym for the new one, and the deprecation warning should indicate that code intended to work with older versions needs to be audited.</p><div><div>
<div class="gmail_quote">On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <<a href="mailto:gabriel439@gmail.com" target="_blank">gabriel439@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
I think it's safer to remove the old function altogether (perhaps
after one deprecation cycle) and provide a new one under a different
name, rather than modify it in place.<br>
<br>
Modifying it in place risks the behavior that others mentioned where
your program is unsafe to compile against older library versions.
Yes, the user could explicitly enforce that by putting a lower bound
on the library, but most users won't even realize that they need to
do that.<br>
<br>
<br>
<div>On 1/6/15, 11:37 AM, Edward Kmett
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I'm +1 for fixing this, in place, on the current
function.
<div><br>
</div>
<div>The specification we have here is doing a very very bad
thing and needs to be fixed, not slavishly copied forward
because someone sometime once made a mistake. </div>
<div><br>
</div>
<div>The current behavior grievously violates the expectations
of anyone who would be in a situation to go and reach for it
and has any prior experience with any other such tool.</div>
<div><br>
</div>
<div>-Edward<br>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jan 6, 2015 at 11:14 AM,
Malcolm Wallace <span dir="ltr"><<a href="mailto:malcolm.wallace@me.com" target="_blank">malcolm.wallace@me.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:<br>
<br>
> On 2015-01-06 14:57, Mike Meyer wrote:<br>
>> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>>
wrote:<br>
>><br>
>>> This is not a bugfix. A bug is failing to
follow the functions<br>
>>> specification, which *does* include following
symlinks.<br>
>>><br>
>><br>
>> It's a bug in the design, not the code.<br>
<br>
</span><span>> Because *nobody* wants to follow
symlinks when doing "rm -rf". Even if<br>
> they think they do, they *really* don't.<br>
<br>
</span>I agree 100%. Even time I use this function, I worry
briefly about whether it follows symlinks, then think to
myself "no, no-one would be so stupid to implement that
deliberately in a publically available API". So it was a
real shock to discover in this thread that I was wrong, and
furthermore that the function is documented as doing the
wrong thing. We should fix both spec and implementation, as
soon as possible.<br>
<br>
Regards,<br>
Malcolm<br>
<div>
<div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Libraries mailing list
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div>
</div></div><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</blockquote></div>