mtl-2.1 severly broken, cabal needs blacklisting

[Andreas Abel]

On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote:
> Blacklisting equals releasing a bugfix.

Not quite.

> Using version number conventions, identifying such a release should be easy.
>
> If there exists a bugfix release for a package currently in use, then
> cabal should emit a warning.

Warnings are easily overlooked.  In a typical cabal install session I 
see tons of irrelevant warnings floating by.

> On Nov 13, 2012 6:12 PM, "Andreas Abel" <andreas.abel at ifi.lmu.de
> <mailto:andreas.abel at ifi.lmu.de>> wrote:
>
>     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.
>         http://www.yesodweb.com/blog/__2012/11/solving-cabal-hell
>         <http://www.yesodweb.com/blog/2012/11/solving-cabal-hell>
>
>
>     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
>
>        mylib-2.1
>        mylib-2.2
>        mylib-3.0
>
>     and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and
>     upload a bugfix version
>
>        mylib-2.1.1
>
>     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 ifi.lmu.de <mailto:andreas.abel at ifi.lmu.de>
>         <mailto:andreas.abel at ifi.lmu.__de
>         <mailto:andreas.abel at ifi.lmu.de>>> 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.
>
>
>         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>
>
>         <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>>
>
>              The bug has been fixed, apparently seven month ago.
>
>         https://github.com/ekmett/mtl/____pull/1
>         <https://github.com/ekmett/mtl/__pull/1>
>              <https://github.com/ekmett/__mtl/pull/1
>         <https://github.com/ekmett/mtl/pull/1>>
>
>              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 ifi.lmu.de <mailto:andreas.abel at ifi.lmu.de>
>     http://www2.tcs.ifi.lmu.de/~__abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>
>     _________________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://www.haskell.org/__mailman/listinfo/libraries
>     <http://www.haskell.org/mailman/listinfo/libraries>
>

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

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

andreas.abel at ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/