206554 2008-01-18 17:27 0000 app-text/acroread-8.1.x can use prebuilt libgtkembedmoz.so from www-client/seamonkey-bin 2008-02-17 22:54:42 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified x86 Linux RESOLVED FIXED P5 trivial --- 1 awaria@chopin.edu.pl kevquinn@gentoo.org printing@gentoo.org awaria@chopin.edu.pl 2008-01-18 17:27:48 0000 It's not necessary for acroread-8.1.x to build either www-client/mozilla-firefox or net-libs/xulrunner (these are both very heavy builds) as acroread can just as well use the libgtkembezmoz.so shared library from the www-client/seamonkey-bin package (/opt/seamonkey/libgtkembedmoz.so). There could also be some einfo telling the user how to select the correct location of the library in his acroread preferences or maybe even a way of setting it systemwide in some rc file. Will look into this possibility later. I would even suggest that this library/dependency be optional, as acroread requires it for certain optional (non-PDF) content and works more or less just fine without it. Reproducible: Always Steps to Reproduce: awaria@chopin.edu.pl 2008-01-18 17:32:39 0000 (In reply to comment #0) > There could also be some einfo telling the user how to select the correct > location of the library in his acroread preferences or maybe even a way of > setting it systemwide in some rc file. Will look into this possibility later. By this I meant that current einfo is a bit vague (a user may have no idea where to look for the library), so it would be nice if einfo provided the library's actual location in the filesystem. tgurr@gentoo.org 2008-01-30 20:38:29 0000 Dependencies are fixed in CVS, seamonkey(-bin) can now also be used. I didn't change the ewarn text for now since it shouldn't happen that no gtkembedmoz.so is installed (via dependency) and properly located by the ebuild. chad@tharasix.com 2008-02-17 20:19:31 0000 While that's a great idea to reduce build times, something got broken during implementation. Now acroread wants to pull in seamonkey-bin even though I have the source seamonkey package in world. [nomerge ] app-text/acroread-8.1.2 [7.0.9-r1] USE="cups nsplugin -ldap" LINGUAS="en -da -de -es -fi -fr -it -ja -ko -nb -nl -pt -sv -zh_CN -zh_TW" [ebuild N ] www-client/seamonkey-bin-1.1.8 14,435 kB Is it time for a new bug, or just reopen this one? tgurr@gentoo.org 2008-02-17 22:54:42 0000 (In reply to comment #3) > While that's a great idea to reduce build times, something got broken during > implementation. Now acroread wants to pull in seamonkey-bin even though I have > the source seamonkey package in world. > > [nomerge ] app-text/acroread-8.1.2 [7.0.9-r1] USE="cups nsplugin -ldap" > LINGUAS="en -da -de -es -fi -fr -it -ja -ko -nb -nl -pt -sv -zh_CN -zh_TW" > [ebuild N ] www-client/seamonkey-bin-1.1.8 14,435 kB > > Is it time for a new bug, or just reopen this one? > If you are on 64bit this is on purpose since acroread is 32bit it also needs a 32bit libgtkembedmoz.so in order to work as expected. And currently seamonkey-bin is the only -bin package which provides the 32bit version of libgtkembedmoz.so on a 64bit platform.