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 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 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@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

xyne:

...

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

If it's possible to install multiple versions of a package with cabal-install, wouldn't it be possible to create pacman packages which install multiple versions as well?

From an outsider's perspective I realize that this may be an ignorant question, but considering the seeming chaos surrounding haskell packages lately and the seeming lack of adherence to uniform standards, perhaps it would be simpler to provide a "parsec" package which contains parsec 2 and parsec 3.

Well, I think there's some very clear standards. - We provide the Haskell Platform spec in [extra] - We provide the maximal coherent install plan in AUR (that is, one version of each package, such that the maximum number of things are installable). What's unusual this time is that some packages got ugpraded without reference to this policy, breaking things.

Such an approach, if possible, would also prevent headaches from other suggested solutions, such as making different versions of the same package available in the official repos and the AUR.

You could use the provides array to specify exactly which packages are provided by a mutli-version package and encourage all haskell packagers to include versions in their depends and makedepends arrays. I haven't tested it but it should be possible to have something along the lines of the following in a depends array: depends=('haskell-parsec>=2' 'haskell-parsec<3')

The merged package could then provide e.g. ('haskell-parsec=2.4' haskell-parsec=3.1').

This would create explicit dependency trees which would prevent mismatch breakage while simultaneously enabling the provision of all popular versions of packages, even when those versions are not part of the current platform.

This could work. It would be different system (we'd be providing a lot more packages). It's something to think about, I think. Anyway, we're in the clear now, at least once vegai updates the last couple of pacakges in [extra] not generated with cabal2arch 0.7 specs. -- Don