On Tue, Nov 13, 2012 at 11:39 PM, Andreas Abel <andreas.abel@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@ifi.lmu.de
<mailto:andreas.abel@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@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de>
        <mailto: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>


        <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@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de>
    http://www2.tcs.ifi.lmu.de/~__abel/ <http://www2.tcs.ifi.lmu.de/~abel/>

    _________________________________________________
    Libraries mailing list
    Libraries@haskell.org <mailto:Libraries@haskell.org>
    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@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/