Currently some packages depends on parsec without any qualifier. However some packages still uses parsec 2 and some packages uses new features of parsec 3. Currently it narrower package depends on more generic package it will result in warning and possible troubles as internals of parsecs are different. Possible solutions: - Get rid of slotting parsecs and patch all packages in repository (can be quite easy as it probably involves changing one line in .cabal). Possibly allowing parsec 3 to be in platform instead of 2. - Mark the packages as parsec3. As in EAPI 3 the packages may specifiy need for specifing USE flags it may work as: DEPEND=">=dev-haskell/network-x.y.z[parsec3]" Reproducible: Always
(In reply to comment #0) > Currently some packages depends on parsec without any qualifier. However some > packages still uses parsec 2 and some packages uses new features of parsec 3. > > Currently it narrower package depends on more generic package it will result in > warning and possible troubles as internals of parsecs are different. Actually, Parsec-3 should be API compatible with Parsec-2. > Possible solutions: > - Get rid of slotting parsecs and patch all packages in repository (can be > quite easy as it probably involves changing one line in .cabal). Possibly > allowing parsec 3 to be in platform instead of 2. 1) We are wary of doing such patching/editing as we prefer to keep things upstream (e.g. Pandoc: John MacFarlane doesn't want to use Parsec-3 yet as its efficiency has only recently been improved; furthermore, he uses Debian and Parsec-3 is still not available there so he can't/refuses to test it). 2) We can't change the platform; it is a set collection of packages designated as a base standard. > - Mark the packages as parsec3. As in EAPI 3 the packages may specifiy need > for specifing USE flags it may work as: > DEPEND=">=dev-haskell/network-x.y.z[parsec3]" That doesn't make sense4. Furthermore, that's in EAPI-2, not 3 and we don't yet have support for any EAPI greater than 0 in hackport. Furthermore, if we were going to do this we'd first be dealing with the profile USE flag problem, not this. If you don't want parsec-3, then mask it (it's a separate slot for a reason).
(In reply to comment #1) > (In reply to comment #0) > > Currently some packages depends on parsec without any qualifier. However some > > packages still uses parsec 2 and some packages uses new features of parsec 3. > > > > Currently it narrower package depends on more generic package it will result in > > warning and possible troubles as internals of parsecs are different. > > Actually, Parsec-3 should be API compatible with Parsec-2. > It implements the API of the parsec 2. > > - Mark the packages as parsec3. As in EAPI 3 the packages may specifiy need > > for specifing USE flags it may work as: > > DEPEND=">=dev-haskell/network-x.y.z[parsec3]" > > That doesn't make sense. Given that there could be a problems with diamond dependencies (A is linked with parsec 2.1, B is linked with 3. If C uses A and B it may cases problems). At least it does not passes checks (ghc-pkg -c) and it 'confuses' cabal-install. Such USE flag would help to avoid such problems. > Furthermore, that's in EAPI-2, not 3 My 'spelling' mistake. > (...) > If you don't want parsec-3, then mask it (it's a separate slot for a reason). > Actually what I want is parsec-3 and ability to install via cabal-install (please don't say that I should not mix portage/overlay and cabal-install - I understend that in overlay there may not be 0-day packages dumps but sometimes in development enviroment they have to be, overlay does not have many packages I need and even if they do exist I'd still prefere to install some of them in $HOME as they rather belongs to dev enviroment then system).
> Actually what I want is parsec-3 and ability to install via cabal-install > (please don't say that I should not mix portage/overlay and cabal-install - I > understend that in overlay there may not be 0-day packages dumps but sometimes > in development enviroment they have to be, overlay does not have many packages > I need and even if they do exist I'd still prefere to install some of them in > $HOME as they rather belongs to dev enviroment then system). You can mask =parsec=-2* and fix everything what breaks. cabal-install forces parsec-2 via 'preferred-versions' mechanism (the file in ~/.cabal/packages/hackage.haskell.org/00-index.tar). I've pushed[1] the USE=noprefs flag to overlay's cabal-install to disabble this strange "feature", which likes to hide breakages and makes cabal-install virtually unusable in gentoo (especially on ghc-6.12+, thanks to abi code in package versions). [1]: http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/cabal-install/cabal-install-0.8.2.ebuild
Unslotted parsec (now in main tree).
