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-Mon... 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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/
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@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/ <http://www2.tcs.ifi.lmu.de/~abel/>
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
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... <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/
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 (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...) <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-Mon...)
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 http://www2.tcs.ifi.lmu.de/~abel/(http://www2.tcs.ifi.lmu.de/~abel/) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe (http://www.haskell.org/mailman/listinfo/haskell-cafe)"
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@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 <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 http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
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@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/Con... <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... <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/
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 <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<andreas.abel@ifi.lmu.de>
<mailto:andreas.abel@ifi.lmu._**_de
<mailto:andreas.abel@ifi.lmu.**de <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>
<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>
<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<andreas.abel@ifi.lmu.de>
http://www2.tcs.ifi.lmu.de/~__**abel/<http://www2.tcs.ifi.lmu.de/~__abel/><; 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> <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/ <http://www2.tcs.ifi.lmu.de/~abel/>
On Wed, 14 Nov 2012, Jean-Philippe Bernardy wrote:
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)
This rule is correct for packages following the Package Versioning Policy. Currently cabal-install and Cabal make no assumptions about the employed versioning scheme.
On 13 November 2012 17:27, Andreas Abel <andreas.abel@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
On Tue, 13 Nov 2012, Bas van Dijk wrote:
On 13 November 2012 17:27, Andreas Abel <andreas.abel@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.
participants (6)
-
Andreas Abel -
Bas van Dijk -
Dan Burton -
Henning Thielemann -
Jean-Philippe Bernardy -
timothyhobbs＠seznam.cz