[arch-haskell] Upgrading to monad-control-0.3

Nicolas Pouillard nicolas.pouillard at gmail.com
Tue Jan 3 21:19:40 CET 2012

On Tue, Jan 3, 2012 at 6:32 PM, Magnus Therning <magnus at therning.org> wrote:
> On Tue, Jan 03, 2012 at 04:07:55PM +0100, Nicolas Pouillard wrote:
>> On Tue, Jan 3, 2012 at 11:39 AM, Peter Hercek <phercek at gmail.com> wrote:
>>> On 01/03/2012 10:18 AM, Magnus Therning wrote:
>>>> On Tue, Jan 3, 2012 at 10:12, Nicolas Pouillard
>>>> <nicolas.pouillard at gmail.com>  wrote:
>>>>> Indeed but I support the concept of the haskell-platform. It is too
>>>>> restrictive to only packages able to track the latest versions of
>>>>> their dependencies.
>>>>> I suggest we try this technique on one case first and the text package
>>>>> seems to be a good example. We could package the latest version of
>>>>> text and upgrade some package which depend on it.
>>>> I'm sorry, but what "technique" are you referring to here?
>> Supporting multiple versions of a package by giving them different
>> archlinux names.
> There is slightly more to it than just giving them different names,
> you'd also have to make sure they don't have any file paths in common.
> Also, if both packages provide docs then one should have precedence
> over the other.

cabal supports installing multiple versions of the same packages so this
should be pretty easy to do the same.

> Also, a practical issue is that `cblrepo` isn't able to handle more
> than a single version of each package in its database.


>>> There was a proposal (in the far past) to add "-hp" to the name of
>>> all packages which belong to haskell platform (HP). The different
>>> name would allow to have a HP package version and one more package
>>> version which was supposed to be the very latest stable version.
>>> HP packages could depend only on other HP packages. Non-HP packages
>>> could depend on HP packages and also on non-HP packages.
>>> Not sure whether there is some fundamental problem why this cannot
>>> work or it was only forgotten. Looks to me like it could work.
>> Indeed this is a solution. However it requires having control on all
>> hp packages which we don't have. However either options are OK for
>> me.
> What would the purpose of providing two versions of some packages be?
> Just to tick the has-haskell-platform box, or is there more value to
> it?
> What packages should be built using the -hp packages?  If any, should
> we try to do anything to avoid the diamond dependency problem?

The purpose is wider than this. Having a second version of a package
(P, V1, V2),
might enable to build a whole set of packages which requires P>V1 while another
set requires P≤V1.

Again, as long as we can push the authors to upgrade their packages
this is fine but we cannot assume this will always be the case.

Nicolas Pouillard

More information about the arch-haskell mailing list