Well, I think this is a reasonable workaround for the "minor" half of
one of these version splitting packages -- I still think we should
downgrade to parsec 2 -- since that's what the haskell platform ships
with.
Now, when we do that, there are a few thiings that need >= parsec 3. For
those, some new logic in cabal2arch got get them building.
We may just be able to get authors to move though, with more direct
calls to stop using non-preferred versions of things.
-- Don
abimelech:
> As a work-around for packages that want parsec 2, as the cabal system allows
> multiple versions of a library to be installed, could one just go ahead and
> install a parsec 2 and let Cabal packages select that? Perhaps name the Arch
> package "parsec2" in the PKGBUILD so it doesn't conflict with parsec 3 when
> having pacman install it. Or just cabal-install.
>> On Mon, Jan 25, 2010 at 4:31 PM, Leif Warner <abimelech at gmail.com> wrote:
>> I've just been taking the "< 3" requirement for parsec out of .cabal files
> - I've found most things still compile with the new version.
> Is it safe to assume it still works if it compiles, or is there a danger in
> doing this?
> -Leif
>>> On Sun, Jan 24, 2010 at 6:15 PM, Don Stewart <dons at galois.com> wrote:
>> The version of parsec in [extra] is 3.x, which isn't part of the
> Haskell Platform.
> This means a lot of stuff doesn't build :/
>> Are there any apps (darcs??) that need parsec3? If not, we should
> switch
> to parsec 2
>> vegai?
>> -- Don
> _______________________________________________
> arch-haskell mailing list
>arch-haskell at haskell.org>http://www.haskell.org/mailman/listinfo/arch-haskell>>>>
> _______________________________________________
> arch-haskell mailing list
>arch-haskell at haskell.org>http://www.haskell.org/mailman/listinfo/arch-haskell