mtl-2.1 severly broken, cabal needs blacklisting
andreas.abel at ifi.lmu.de
Tue Nov 13 23:39:45 CET 2012
On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote:
> 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.
Warnings are easily overlooked. In a typical cabal install session I
see tons of irrelevant warnings floating by.
> On Nov 13, 2012 6:12 PM, "Andreas Abel" <andreas.abel at ifi.lmu.de
> <mailto: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.
> 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
> and I discover a bug in mylib-2.1, I could blacklist mylib-2.1 and
> upload a bugfix version
> 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>
> <mailto: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
> The bug has been fixed, apparently seven month ago.
> However, the "malicious" mtl-2.1 still lingers on: it is
> from hackage and installed in many systems.
> This calls for a means of blacklisting broken or malicious
> cabal update
> should also pull a blacklist of packages that will never be
> by cabal install (except maybe by explicit user safety
> I think such a mechanism is not only necessary for security
> purposes, but also to safe the valuable resources of our
> 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>
> 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>
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
More information about the Libraries