Andreas Abel | 13 Nov 17:27 2012
Picon

mtl-2.1 severly broken, cabal needs blacklisting

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

The bug has been fixed, apparently seven month ago.

   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
(Continue reading)

Dan Burton | 13 Nov 17:39 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting

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


-- Dan Burton (801-513-1596)


On Tue, Nov 13, 2012 at 9:27 AM, Andreas Abel <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

The bug has been fixed, apparently seven month ago.

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

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Andreas Abel | 13 Nov 18:11 2012
Picon

Re: 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 <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 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 <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
timothyhobbs | 13 Nov 18:19 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting

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 <at> 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 <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 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 <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jean-Philippe Bernardy | 13 Nov 23:13 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting

My take:

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.

Cheers,
JP.

On Nov 13, 2012 6:12 PM, "Andreas Abel" <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

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>> 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 <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Andreas Abel | 13 Nov 23:39 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting

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

Not quite.

> 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.
>         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>
>         <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
>         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 <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>
>     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/
Jean-Philippe Bernardy | 14 Nov 08:52 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting




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


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

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 14 Nov 19:04 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting


On Wed, 14 Nov 2012, Jean-Philippe Bernardy wrote:

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

This rule is correct for packages following the Package Versioning Policy.
Currently cabal-install and Cabal make no assumptions about the employed 
versioning scheme.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Bas van Dijk | 13 Nov 18:30 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting

On 13 November 2012 17:27, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
> 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).

Maybe we can use the existing preferred-versions file that cabal-install uses:

http://hackage.haskell.org/packages/archive/preferred-versions

Bas
Henning Thielemann | 13 Nov 20:03 2012
Picon

Re: mtl-2.1 severly broken, cabal needs blacklisting


On Tue, 13 Nov 2012, Bas van Dijk wrote:

> On 13 November 2012 17:27, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
>> 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).
>
> Maybe we can use the existing preferred-versions file that cabal-install uses:
>
> http://hackage.haskell.org/packages/archive/preferred-versions

It is also possible to deprecate a package. Is it possible to deprecate a 
single version? I'm afraid that the user is also not warned if he installs 
a deprecated package.

Gmane