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

My take: Blacklisting equals releasing a bugfix. 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. Cheers, JP. On Nov 13, 2012 6:12 PM, "Andreas Abel" 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-hellhttp://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

...

>> 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#modifyhttp://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#modifyhttp://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/1https://github.com/ekmett/mtl/__pull/1 <https://github.com/ekmett/**mtl/pull/1https://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/

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries