<p>My take:</p>
<p>Blacklisting equals releasing a bugfix.</p>
<p>Using version number conventions, identifying such a release should be easy.</p>
<p>If there exists a bugfix release for a package currently in use, then cabal should emit a warning.<br></p>
<p>Cheers,<br>
JP.</p>
<div class="gmail_quote">On Nov 13, 2012 6:12 PM, "Andreas Abel" <<a href="mailto:andreas.abel@ifi.lmu.de">andreas.abel@ifi.lmu.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 13.11.2012 17:39, Dan Burton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mixed feelings here. I personally subscribe to the philosophy of "do one<br>
thing and do it well"; perhaps this sort of functionality would be<br>
better delegated to a new "curation" tool such as the one described in<br>
Michael Snoyman's recent blog post.<br>
<a href="http://www.yesodweb.com/blog/2012/11/solving-cabal-hell" target="_blank">http://www.yesodweb.com/blog/<u></u>2012/11/solving-cabal-hell</a><br>
</blockquote>
<br>
I think Michael Snoyman's approach goes farther than mine and solves a slightly different problem. I am not concerned with the "dependency 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 does not provide a suitable means to rectify the situation. Cabal's philosophy currently includes a monotonicity assumption: newer is better and more correct. As a consequence, packages do not get removed or replaced since that could break compilation of other packages depending on a special version number of a package. The calamity is that bugged 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 the next higher available version, as a sort of redirection mechanism to 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 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 (e.g. having a constraint mylib == 2.1) and do not work with mylib-2.2 would still work, since they would be built with mylib-2.1.1<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a><br>
<mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.<u></u>de</a>>> wrote:<br>
<br>
After 2 days of shrinking 251 modules of source code to a few lines<br>
I realized that modify in MonadState causes <<loop>> in mtl-2.1.<br>
<br>
<br>
<a href="http://hackage.haskell.org/__packages/archive/mtl/2.1/doc/__html/src/Control-Monad-State-__Class.html#modify" target="_blank">http://hackage.haskell.org/__<u></u>packages/archive/mtl/2.1/doc/_<u></u>_html/src/Control-Monad-State-<u></u>__Class.html#modify</a><br>
<<a href="http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify" target="_blank">http://hackage.haskell.org/<u></u>packages/archive/mtl/2.1/doc/<u></u>html/src/Control-Monad-State-<u></u>Class.html#modify</a>><br>
<br>
The bug has been fixed, apparently seven month ago.<br>
<br>
<a href="https://github.com/ekmett/mtl/__pull/1" target="_blank">https://github.com/ekmett/mtl/<u></u>__pull/1</a><br>
<<a href="https://github.com/ekmett/mtl/pull/1" target="_blank">https://github.com/ekmett/<u></u>mtl/pull/1</a>><br>
<br>
However, the "malicious" mtl-2.1 still lingers on: it is available<br>
from hackage and installed in many systems.<br>
<br>
This calls for a means of blacklisting broken or malicious packages.<br>
<br>
cabal update<br>
<br>
should also pull a blacklist of packages that will never be selected<br>
by cabal install (except maybe by explicit user safety overriding).<br>
<br>
I think such a mechanism is not only necessary for security<br>
purposes, but also to safe the valuable resources of our community.<br>
<br>
Cheers,<br>
Andreas<br>
</blockquote>
<br>
-- <br>
Andreas Abel <>< Du bist der geliebte Mensch.<br>
<br>
Theoretical Computer Science, University of Munich<br>
Oettingenstr. 67, D-80538 Munich, GERMANY<br>
<br>
<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a><br>
<a href="http://www2.tcs.ifi.lmu.de/~abel/" target="_blank">http://www2.tcs.ifi.lmu.de/~<u></u>abel/</a><br>
<br>
______________________________<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>