emerge of xmonad-0.9 fails with the following: >>> Unpacking source... >>> Unpacking xmonad-0.9.tar.gz to /var/tmp/portage/x11-wm/xmonad-0.9/work >>> Source unpacked in /var/tmp/portage/x11-wm/xmonad-0.9/work >>> Compiling source in /var/tmp/portage/x11-wm/xmonad-0.9/work/xmonad-0.9 ... * Using cabal-1.6.0.3. [1 of 1] Compiling Main ( /var/tmp/portage/x11-wm/xmonad-0.9/work/xmonad-0.9/Setup.lhs, /var/tmp/portage/x11-wm/xmonad-0.9/work/xmonad-0.9/Setup.o ) Linking setup ... Configuring xmonad-0.9... setup: At least the following dependencies are missing: mtl -any After emerging dev-haskell/mtl, xmonad-0.9 emerges successfully. Reproducible: Always Steps to Reproduce: 1. If present, unmerge dev-haskell/mtl 2. emerge x11-wm/xmonad-0.9
fixed sometime over the past few days
/facepalm I was wrong. This bug has not been fixed. 'dev-haskell/mtl' was always listed as a dependency in the ebuild, even for xmonad-0.8.1 and prior, but portage doesn't seem to see it. If you manually install it with 'emerge -1 dev-haskell/mtl', doing an 'emerge --depclean' will see that it's a dependency and will not remove it. Could this be a portage bug? I'm using portage-2.2_rc49
(In reply to comment #2) > /facepalm > I was wrong. This bug has not been fixed. 'dev-haskell/mtl' was always listed > as a dependency in the ebuild, even for xmonad-0.8.1 and prior, but portage > doesn't seem to see it. If you manually install it with 'emerge -1 > dev-haskell/mtl', doing an 'emerge --depclean' will see that it's a dependency > and will not remove it. > > Could this be a portage bug? I'm using portage-2.2_rc49 > Dependency on dev-haskell/mtl works fine here with sys-apps/portage-2.2_rc58. Can you check with this version(or portage-2.2_rc60 is in the tree).
Could it be that you've upgraded ghc and not reinstalled mtl? In that case you might already have had mtl and thus satisfied the dependency, but your new ghc did not know about it. We've built an application called 'haskell-updater' to deal with exactly this case, for ghc 6.10. You can try to run $ haskell-updater -p and see if it can find something else too, maybe. Let us know how it works out.
Closing as INVALID as it looks like mtl was not fixed by haskell-updater after ghc upgrade. Please reopen if I am wrong and bug is reproduceable without 'ghc upgrade'/'mtl breakage' in the middle.
