maybe this is a valid depend, but i doubt it ... the hard depend on readline-5 prevents installation of readline-6
ghc-6.8.2 works fine with readline-6 here (amd64). So please replace readline-5 with readline in the ebuild. Thanks.
Maybe something like this: --- ghc-6.8.2.ebuild 2008-10-04 12:35:49.000000000 +0200 +++ ghc-6.8.2-r1.ebuild 2009-02-22 11:03:15.755939127 +0100 @@ -57,7 +57,7 @@ >=sys-devel/binutils-2.17 >=dev-lang/perl-5.6.1 >=dev-libs/gmp-4.1 - =sys-libs/readline-5*" + >=sys-libs/readline-5" DEPEND="${RDEPEND} ghcbootstrap? ( doc? ( ~app-text/docbook-xml-dtd-4.2
*** Bug 259958 has been marked as a duplicate of this bug. ***
Trouble is that our binaries used to bootstrap ghc are linked against readline-5. $ readelf -d usr/lib64/ghc-6.8.2/ghc-6.8.2 Dynamic section at offset 0xef3dc0 contains 29 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libreadline.so.5] [snap] octoploid, building ghc only works as long as you keep your old readline-5 .sos around, like emerge does if you upgrade it while still having packages depending on it. Simply changing the dependency would cause cause the ebuild to fail unless having both libreadline-5 and -6, and we obviously don't want that. What are our options? 1) Having a statically liked binary for bootstrapping. This requires rebuilding of all the binaries though... not tempted to do this for stable ebuilds. 2) Let the stable ghc depend on the stable readline. GHC 6.10.1 is available from the overlay, and will be added we get bug #237882 solved. It's unfortunate though that the latest ghc doesn't work with the latest readline. What else? Are readline-5 and readline-6 ABI compatible?
if they were ABI compatible, they'd have the same SONAME by bootstrapping, do you mean the ghc-bin packages ? statically linking those against readline for now would seem like an OK workaround
(In reply to comment #4) > What else? 3) ship precompiled readline 5 library along with bootstrap binaries. You could include them using LD_LIBRARY_PATH from somewhere withing $WORKDIR. When you are dealing with precompiled binaries in any case, one precompiled lib won't hurt, will it? And getting those from the tinderboxes should be easy.
(In reply to comment #5) > by bootstrapping, do you mean the ghc-bin packages ? statically linking those > against readline for now would seem like an OK workaround Mmmm.. not the dev-lang/ghc-bin packages, no. The binaries for the bootstrapping have been included into the regular dev-lang/ghc ebuild, there is no longer two separate ebuilds for this. The old dev-lang/ghc-bin packages should be removed from the portage tree, they've been hard masked for a long time. Statically linking to readline would indeed solve the issue. We support 8 arches though, so there is quite some work. Also, I've not yet figured out how to modify the build system in order to get a static executable. (In reply to comment #6) > (In reply to comment #4) > > What else? > > 3) ship precompiled readline 5 library along with bootstrap binaries. > > You could include them using LD_LIBRARY_PATH from somewhere withing $WORKDIR. > When you are dealing with precompiled binaries in any case, one precompiled lib > won't hurt, will it? And getting those from the tinderboxes should be easy. This sounds even more interesting. We could try to do a proper static build for the next ghc 6.10.1 version, but use this shorter path for our existing binaries. I guess we would also have to remove the flag USE="binary" as it'd install a ghc that depended on readline-5. Bootstrapping with the precompiled readline would be ok, but it might not be such a good idea to install the precompiled lib :)
I've uploaded an ebuild to the overlay (based on the overlay ebuild which is slightly different) that does option (3) for x86. http://code.haskell.org/gentoo/gentoo-haskell/dev-lang/ghc/ghc-6.8.2-r1.ebuild Everybody agrees this is a good way to solve it? Seems like a nice and easy way to go to me. Wed Feb 25 18:48:22 CET 2009 Lennart Kolmodin <kolmodin@gentoo.org> * Add a new ghc-6.8.2-r1 that works even if host system uses readline-6 See gentoo bug #259867. This ebuild bundles a precompiled sys-libs/readline-5.2_p13 and uses that to make the bundled ghc binary work if the host machine has upgraded to readline-6. It sets the LD_LIBRARY_PATH flag into ${WORKDIR}/lib. To build precompiled readlines, run emerge -b '<sys-libs/readline-6' and name the resulting file like I've for the x86 in the ebuild. Edit the ebuild SRC_URI, KEYWORDS, and potentially the code that sets the LD_LIBRARY_PATH to handle /lib{,32,64}.
I put the ebuild of comment #8 to /usr/local/portage/dev-lang/ghc . Did a 'ebuild ghc-6.8.2-r1.ebuild digest'. I have PORTDIR_OVERLAY="/usr/local/portage" in /etc/make.conf and normally no problems with overlays. But 'emerge ghc' wants to emerge ghc-6.8.2 and not ghc-6.8.2-r1: root@condor:/usr/local/portage/dev-lang/ghc(19)# emerge -pvD ghc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-libs/readline-5.2_p13 [6.0] 0 kB [0] [ebuild N ] dev-lang/ghc-6.8.2 USE="bash-completion doc -binary -ghcbootstrap" 0 kB [1] Total: 2 packages (1 downgrade, 1 new), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /usr/local/portage Any idea?
When I made the new ebuild I changed the keywording from x86 to ~x86. Have you got dev-lang/ghc in your /etc/portage/package.keywords file?
Thanks. After adding dev-lang/ghc ~* * to /etc/portage/package.keywords it works.
I did the whole cycle on ~x86: emerged ghc to get updated ebuild without fixed dependency, updated world, rebuilt to get rid of preserved readline 5, and emerged ghc again. So with the ebuild from overlay, compiling under both readline 5 and 6 seems to work well enough, and the migration path held no surprising obstacles for me either. Ready for main portage tree?
It seems it doesn't work with readline-5, emerge and FEATURES="collision-protect". For some reason it seems to install the bundled readline-5? Seems paludis does not have this trouble.
(In reply to comment #13) > It seems it doesn't work with readline-5, emerge and > FEATURES="collision-protect". > > For some reason it seems to install the bundled readline-5? > Seems paludis does not have this trouble. > dev-lang/ghc-6.8.2-r1 works correctly if USE="-binary" (that's why paludis might not detect that collision) USE=binary will cause: * readline-5 binary dependency: leads to troubles when upgrade to readline-6 (fixable by reemerging ghc with USE="-binary") * ghc will fail to emerge with FEATURES="collision-protect": ghc-bin will collide at installation with readline package: it's caused, because we just unpack 2 tarballs(ghc-bin+readline-5+bin) into 1 directory and declare it as resulting to-be-merged tree.
(In reply to comment #14) > USE=binary will cause: > * readline-5 binary dependency: > leads to troubles when upgrade to readline-6 > (fixable by reemerging ghc with USE="-binary") > * ghc will fail to emerge with FEATURES="collision-protect": > ghc-bin will collide at installation with readline package: it's caused, > because we just unpack 2 tarballs(ghc-bin+readline-5+bin) into 1 directory > and declare it as resulting to-be-merged tree. Indeed, allowing USE=binary would introduce a hidden dependency to =readline-5, which is exactly what we don't want. The merges of ghc-bin and readline was a bug, and will also go away if we disallow USE=binary. Thus, I've updated the ghc-6.8.2-r1 ebuild in the overlay to not include IUSE=binary.
(In reply to comment #8) > I've uploaded an ebuild to the overlay (based on the overlay ebuild which is > slightly different) that does option (3) for x86. I just tried this ebuild on amd64, and it seems to be able to compile (almost) everything. It died with this error: ------------------------------------------------------------------------ == make install -r; in /var/tmp/portage/dev-lang/ghc-6.8.2-r1/work/ghc-6.8.2/libraries/Cabal/doc ------------------------------------------------------------------------ make[1]: Nothing to be done for `install'. ./utils/mkdirhier/mkdirhier /var/tmp/portage/dev-lang/ghc-6.8.2-r1/image//usr/lib64/ghc-6.8.2 /usr/bin/install -c -m 644 extra-gcc-opts /var/tmp/portage/dev-lang/ghc-6.8.2-r1/image//usr/lib64/ghc-6.8.2 !!! dosbin: /usr/local/portage/dev-lang/ghc/files/ghc-updater does not exist !!! newins: /usr/local/portage/dev-lang/ghc/files/ghc-bash-completion does not exist
(In reply to comment #16) > I just tried this ebuild on amd64, and it seems to be able to compile (almost) > everything. It died with this error: > ------------------------------------------------------------------------ > == make install -r; > in /var/tmp/portage/dev-lang/ghc-6.8.2-r1/work/ghc-6.8.2/libraries/Cabal/doc > ------------------------------------------------------------------------ > make[1]: Nothing to be done for `install'. > ./utils/mkdirhier/mkdirhier > /var/tmp/portage/dev-lang/ghc-6.8.2-r1/image//usr/lib64/ghc-6.8.2 > /usr/bin/install -c -m 644 extra-gcc-opts > /var/tmp/portage/dev-lang/ghc-6.8.2-r1/image//usr/lib64/ghc-6.8.2 > !!! dosbin: /usr/local/portage/dev-lang/ghc/files/ghc-updater does not exist > !!! newins: /usr/local/portage/dev-lang/ghc/files/ghc-bash-completion does not > exist > This is very odd. Do you indeed not have these files? /usr/local/portage/dev-lang/ghc/files/ghc-updater /usr/local/portage/dev-lang/ghc/files/ghc-bash-completion Any files in ghc/files/? Please verify that your repo is ok.
Got the same exact error. Confirmed that directory /usr/local/portage/dev-lang/ghc/files/ does not even exist.
I see. Are you using layman? Also try this: $ cat /usr/local/portage/_darcs/prefs/defaultrepo code.haskell.org:/srv/code/gentoo/gentoo-haskell $ cd /usr/local/portage/ $ darcs whatsnew . No changes! $ darcs pull Pulling from "code.haskell.org:/srv/code/gentoo/gentoo-haskell"... This is the gentoo-haskell darcs overlay. Please report bugs in the IRC channel #gentoo-haskell on the freenode network, or send mail to haskell@gentoo.org. Please do *not* report bugs from this overlay at bugs.gentoo.org. ********************** No remote changes to pull in! --------- Do you get the messages like above?
(In reply to comment #17) > (In reply to comment #16) > > I just tried this ebuild on amd64, and it seems to be able to compile (almost) > > everything. It died with this error: > > ------------------------------------------------------------------------ > > == make install -r; > > in /var/tmp/portage/dev-lang/ghc-6.8.2-r1/work/ghc-6.8.2/libraries/Cabal/doc > > ------------------------------------------------------------------------ > > make[1]: Nothing to be done for `install'. > > ./utils/mkdirhier/mkdirhier > > /var/tmp/portage/dev-lang/ghc-6.8.2-r1/image//usr/lib64/ghc-6.8.2 > > /usr/bin/install -c -m 644 extra-gcc-opts > > /var/tmp/portage/dev-lang/ghc-6.8.2-r1/image//usr/lib64/ghc-6.8.2 > > !!! dosbin: /usr/local/portage/dev-lang/ghc/files/ghc-updater does not exist > > !!! newins: /usr/local/portage/dev-lang/ghc/files/ghc-bash-completion does not > > exist > > > > This is very odd. Do you indeed not have these files? > /usr/local/portage/dev-lang/ghc/files/ghc-updater > /usr/local/portage/dev-lang/ghc/files/ghc-bash-completion > Any files in ghc/files/? > > Please verify that your repo is ok. > I messed up - I didn't copy the existing files from /usr/portage/... to my overlay. After I did that, the new ebuild emerged successfully, and life is good. No more readline-5 dependency, ghc works... This is great!
(In reply to comment #19) > I see. Are you using layman? > > Also try this: > > $ cat /usr/local/portage/_darcs/prefs/defaultrepo > code.haskell.org:/srv/code/gentoo/gentoo-haskell > > $ cd /usr/local/portage/ > $ darcs whatsnew . > No changes! > > $ darcs pull > Pulling from "code.haskell.org:/srv/code/gentoo/gentoo-haskell"... > This is the gentoo-haskell darcs overlay. > > Please report bugs in the IRC channel #gentoo-haskell on the freenode > network, or send mail to haskell@gentoo.org. > > Please do *not* report bugs from this overlay at bugs.gentoo.org. > ********************** > No remote changes to pull in! > > --------- > > Do you get the messages like above? > Yes, using Layman.
Pushed ghc-6.8.2-r1 to the portage tree, hard masked. Please try it and report back. http://linuxreviews.org/gentoo/masked_packages/ I'll unmask it the next couple of days if things work nicely. So far it's only for x86 and amd64. This ghc version won't be very interesting once we've put ghc 6.10.2 into the tree, which is where our main efforts are atm.
#[ebuild N ] dev-haskell/network-2.2.1 USE="-doc -profile" #[ebuild N ] dev-util/darcs-2.1.0-r1 USE="-doc" ******** I thought the whole point was to NOT install readline-5.2... Emerged darcs, layman -a haskell, removed readline 5.2, revdep-rebuild, ghc-updater caused ********* * Failed Packages: * ---------------- * These packages have failed and need to be re-emerged again. * Alternatively, try re-running this script again to see if it * can be fixed. * emerge -p '>='dev-haskell/gtk2hs-0.9.12.1 re-emerged gtk2hs, re-ran ghc-updater, tried emerge --depclean and was getting nags about package dev-haskell/bytestring-0.9.1.4, manually emerged bytestring emerge --depclean started working at this point. No nags about readline-5.2
Now that readline-6_p3 got stable for "alpha amd64 hppa ppc64 x86", we should really get the fix in stable too.
(now stable everywhere) ghc-6.12.3 got rid of readline depend
