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

[timothyhobbs at seznam.cz]

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 <andreas.abel at ifi.lmu.de>
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 <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
http://www2.tcs.ifi.lmu.de/~abel/(http://www2.tcs.ifi.lmu.de/~abel/)

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
(http://www.haskell.org/mailman/listinfo/haskell-cafe)"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121113/4e8822f3/attachment.htm>