[arch-haskell] parsec troubles
dons at galois.com
Mon Feb 1 00:41:49 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.
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'
> 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.
More information about the arch-haskell