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

Jean-Philippe Bernardy jeanphilippe.bernardy at gmail.com
Wed Nov 14 08:52:00 CET 2012


On Tue, Nov 13, 2012 at 11:39 PM, Andreas Abel <andreas.abel at ifi.lmu.de>wrote:

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


I propose to *define* blacklisting as such.

package-X.Y.Z.W is blacklisted if there exists package-X.Y.Z.V where V > W
(maybe I'm off by one position in the  version number scheme here, but you
get the idea)

The advantages of this proposal are
 * backward and forward compatible with all existing code, including hackage
 * minimal addition to cabal-install: add some code to detect compilation
against a blacklisted version


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

WARNING: This package is compiled against known incorrect code! You should
upgrade the mtl package.

would show up at *every compilation*.

I am guessing this would have been sufficient to save you from a 250-module
shrinking.

By the way, the new warning is effective only if one has an up-to-date list
of packages.
Hence it makes sense to group it with the current warning about an
out-of-date list.

Cheers,
JP.


>
>  On Nov 13, 2012 6:12 PM, "Andreas Abel" <andreas.abel at ifi.lmu.de
>> <mailto:andreas.abel at ifi.lmu.**de <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>
>>
>>         <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>
>> >
>>         <mailto: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>
>> >
>>
>>
>>         <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>
>> >
>>
>>              <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<andreas.abel at ifi.lmu.de>
>> >
>>     http://www2.tcs.ifi.lmu.de/~__**abel/<http://www2.tcs.ifi.lmu.de/~__abel/><
>> 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>
>>     <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/ <http://www2.tcs.ifi.lmu.de/~abel/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121114/520872ec/attachment-0001.htm>


More information about the Haskell-Cafe mailing list