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
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.a...@ifi.lmu.de
<mailto:andreas.a...@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>
The bug has been fixed, apparently seven month ago.
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.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
