[arch-haskell] parsec troubles

Xyne xyne at archlinux.ca
Sun Jan 31 23:32:31 EST 2010


> 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.

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.



Sorry if this is blatantly a bad idea and/or impossible. I'm just
thinking out loud. I suspect that the feasibility of this approach
depends on how multiple versions of the same package are
handled by cabal-install, and I have no idea how they are.



Regards,
Xyne


More information about the arch-haskell mailing list