mtl-2.1 severly broken, cabal needs blacklisting

Andreas Abel andreas.abel at
Tue Nov 13 18:11:04 CET 2012

On 13.11.2012 17:39, Dan Burton wrote:
> Mixed feelings here. I personally subscribe to the philosophy of "do one
> thing and do it well"; perhaps this sort of functionality would be
> better delegated to a new "curation" tool such as the one described in
> Michael Snoyman's recent blog post.

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.

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.

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


and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and 
upload a bugfix version


that would be picked by cabal instead of mylib-2.1.

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

> On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <andreas.abel at
> <mailto:andreas.abel at>> wrote:
>     After 2 days of shrinking 251 modules of source code to a few lines
>     I realized that modify in MonadState causes <<loop>> in mtl-2.1.
>     <>
>     The bug has been fixed, apparently seven month ago.
>     <>
>     However, the "malicious" mtl-2.1 still lingers on: it is available
>     from hackage and installed in many systems.
>     This calls for a means of blacklisting broken or malicious packages.
>        cabal update
>     should also pull a blacklist of packages that will never be selected
>     by cabal install (except maybe by explicit user safety overriding).
>     I think such a mechanism is not only necessary for security
>     purposes, but also to safe the valuable resources of our community.
>     Cheers,
>     Andreas

Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel at

More information about the Libraries mailing list