mtl-2.1 severly broken, cabal needs blacklisting

[Jean-Philippe Bernardy]

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" <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 <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/>
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121113/0add7b32/attachment-0001.htm>