<html><body>I agree with Andreas, we need a "package recall" method.&nbsp; This should be an ability granted only to certain people, so that all of hackage cannot be deleted by one rogue user with recall privileges, but this is still a necessary feature.<br><br>Timothy<br><p><br>---------- Původní zpráva ----------<br>Od: Andreas Abel &lt;andreas.abel@ifi.lmu.de&gt;<br>Datum: 13. 11. 2012<br>Předmět: Re: [Haskell-cafe] mtl-2.1 severly broken, cabal needs blacklisting</p><blockquote>On 13.11.2012 17:39, Dan Burton wrote:<br>&gt; Mixed feelings here. I personally subscribe to the philosophy of "do one<br>&gt; thing and do it well"; perhaps this sort of functionality would be<br>&gt; better delegated to a new "curation" tool such as the one described in<br>&gt; Michael Snoyman's recent blog post.<br>&gt; <a href="http://www.yesodweb.com/blog/2012/11/solving-cabal-hell">http://www.yesodweb.com/blog/2012/11/solving-cabal-hell</a><br><br>I think Michael Snoyman's approach goes farther than mine and solves a <br>slightly different problem.  I am not concerned with the "dependency <br>hell" but with a means of safely avoiding bugged packages.<br><br>Uploading a bugged package can happen to anyone of us, but cabal/hackage <br>does not provide a suitable means to rectify the situation.  Cabal's <br>philosophy currently includes a monotonicity assumption: newer is better <br>and more correct.  As a consequence, packages do not get removed or <br>replaced since that could break compilation of other packages depending <br>on a special version number of a package.  The calamity is that bugged <br>package live on, and cabal install is oblivious of this.<br><br>If one could blacklist a certain version of a package, cabal could pick <br>the next higher available version, as a sort of redirection mechanism to <br>the fixed package.  For instance, if I have issued<br><br>   mylib-2.1<br>   mylib-2.2<br>   mylib-3.0<br><br>and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and <br>upload a bugfix version<br><br>   mylib-2.1.1<br><br>that would be picked by cabal instead of mylib-2.1.<br><br>Those user packages that rely on the specific interface of mylib-2.1 <br>(e.g. having a constraint mylib == 2.1) and do not work with mylib-2.2 <br>would still work, since they would be built with mylib-2.1.1<br><br>&gt; On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel &lt;andreas.abel@ifi.lmu.de<br>&gt; &lt;mailto:andreas.abel@ifi.lmu.de&gt;&gt; wrote:<br>&gt;<br>&gt;     After 2 days of shrinking 251 modules of source code to a few lines<br>&gt;     I realized that modify in MonadState causes &lt;&lt;loop&gt;&gt; in mtl-2.1.<br>&gt;<br>&gt;<br>&gt;     <a href="http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control-Monad-State-__Class.html#modify">http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control-Monad-State-__Class.html#modify</a><br>&gt;     &lt;<a href="http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify">http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify</a>&gt;<br>&gt;<br>&gt;     The bug has been fixed, apparently seven month ago.<br>&gt;<br>&gt;     <a href="https://github.com/ekmett/mtl/__pull/1">https://github.com/ekmett/mtl/__pull/1</a><br>&gt;     &lt;<a href="https://github.com/ekmett/mtl/pull/1">https://github.com/ekmett/mtl/pull/1</a>&gt;<br>&gt;<br>&gt;     However, the "malicious" mtl-2.1 still lingers on: it is available<br>&gt;     from hackage and installed in many systems.<br>&gt;<br>&gt;     This calls for a means of blacklisting broken or malicious packages.<br>&gt;<br>&gt;        cabal update<br>&gt;<br>&gt;     should also pull a blacklist of packages that will never be selected<br>&gt;     by cabal install (except maybe by explicit user safety overriding).<br>&gt;<br>&gt;     I think such a mechanism is not only necessary for security<br>&gt;     purposes, but also to safe the valuable resources of our community.<br>&gt;<br>&gt;     Cheers,<br>&gt;     Andreas<br><br>-- <br>Andreas Abel  &lt;&gt;&lt;      Du bist der geliebte Mensch.<br><br>Theoretical Computer Science, University of Munich<br>Oettingenstr. 67, D-80538 Munich, GERMANY<br><br>andreas.abel@ifi.lmu.de<br><a href="http://www2.tcs.ifi.lmu.de/~abel/">http://www2.tcs.ifi.lmu.de/~abel/</a><br><br>_______________________________________________<br>Haskell-Cafe mailing list<br>Haskell-Cafe@haskell.org<br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a></blockquote></body></html>