Re: [Haskell-cafe] mtl-2.1 severly broken, cabal needs blacklisting

I agree with Andreas, we need a "package recall" method.  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. Timothy ---------- Původní zpráva ---------- Od: Andreas Abel Datum: 13. 11. 2012 Předmět: Re: [Haskell-cafe] mtl-2.1 severly broken, cabal needs blacklisting "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 mailto:andreas.abel@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...) <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-Mon...)

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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/(http://www2.tcs.ifi.lmu.de/~abel/) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe (http://www.haskell.org/mailman/listinfo/haskell-cafe)"