[arch-haskell] Upgrading to monad-control-0.3
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
> 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
> 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.
More information about the arch-haskell