<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 11:39 PM, Andreas Abel <span dir="ltr"><<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Blacklisting equals releasing a bugfix.<br>
</blockquote>
<br></div>
Not quite.</blockquote><div><br></div><div>I propose to *define* blacklisting as such. </div><div><br></div><div>package-X.Y.Z.W is blacklisted if there exists package-X.Y.Z.V where V > W</div><div>(maybe I'm off by one position in the version number scheme here, but you get the idea)</div>
<div><br></div><div>The advantages of this proposal are</div><div> * backward and forward compatible with all existing code, including hackage<br></div><div> * minimal addition to cabal-install: add some code to detect compilation against a blacklisted version</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"></div>
Warnings are easily overlooked. In a typical cabal install session I see tons of irrelevant warnings floating by.<br></blockquote><div><br></div><div>WARNING: This package is compiled against known incorrect code! You should upgrade the mtl package.</div>
<div><br></div><div>would show up at *every compilation*. </div><div><br></div><div>I am guessing this would have been sufficient to save you from a 250-module shrinking.</div><div><br></div><div><div>By the way, the new warning is effective only if one has an up-to-date list of packages.</div>
<div>Hence it makes sense to group it with the current warning about an out-of-date list.</div></div><div><br></div><div>Cheers,</div><div>JP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Nov 13, 2012 6:12 PM, "Andreas Abel" <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a><br></div><div class="im">
<mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.<u></u>de</a>>> wrote:<br>
<br>
On 13.11.2012 17:39, Dan Burton wrote:<br>
<br>
Mixed feelings here. I personally subscribe to the philosophy of<br>
"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<br>
described in<br>
Michael Snoyman's recent blog post.<br></div>
<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><div><div class="h5"><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>
<br>
<br>
I think Michael Snoyman's approach goes farther than mine and solves<br>
a slightly different problem. I am not concerned with the<br>
"dependency hell" but with a means of safely avoiding bugged packages.<br>
<br>
Uploading a bugged package can happen to anyone of us, but<br>
cabal/hackage does not provide a suitable means to rectify the<br>
situation. Cabal's philosophy currently includes a monotonicity<br>
assumption: newer is better and more correct. As a consequence,<br>
packages do not get removed or replaced since that could break<br>
compilation of other packages depending on a special version number<br>
of a package. The calamity is that bugged package live on, and<br>
cabal install is oblivious of this.<br>
<br>
If one could blacklist a certain version of a package, cabal could<br>
pick the next higher available version, as a sort of redirection<br>
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<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<br>
mylib-2.2 would still work, since they would be built with mylib-2.1.1<br>
<br>
On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel<br>
<<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a> <mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.<u></u>de</a>><br></div></div>
<mailto:<a href="mailto:andreas.abel@ifi.lmu." target="_blank">andreas.abel@ifi.lmu.</a>_<u></u>_de<div class="im"><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<br>
few lines<br>
I realized that modify in MonadState causes <<loop>> in<br>
mtl-2.1.<br>
<br>
<br></div>
<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-<u></u>State-____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>><div class="im">
<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></div>
<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>><div class="im"><br>
<<a href="https://github.com/ekmett/__mtl/pull/1" target="_blank">https://github.com/ekmett/__<u></u>mtl/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<br>
available<br>
from hackage and installed in many systems.<br>
<br>
This calls for a means of blacklisting broken or malicious<br>
packages.<br>
<br>
cabal update<br>
<br>
should also pull a blacklist of packages that will never be<br>
selected<br>
by cabal install (except maybe by explicit user safety<br>
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<br>
community.<br>
<br>
Cheers,<br>
Andreas<br>
<br>
<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></div>
<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a> <mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.<u></u>de</a>><br>
<a href="http://www2.tcs.ifi.lmu.de/~__abel/" target="_blank">http://www2.tcs.ifi.lmu.de/~__<u></u>abel/</a> <<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> <mailto:<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>
<<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a>><br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<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>
</div></div></blockquote></div><br></div>