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@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

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@ifi.lmu.de
> <mailto:andreas.abel@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.abel@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