app-text/acroread RDEPENDs on someone bringing in XUL. On amd64, only net-libs/xulrunner-bin and www-client/seamonkey-bin are considered. However, with net-libs/xulrunner (not -bin) installed, acroread now compiles and runs fine. acroread should not force bin versions of packages any more. Reproducible: Always Steps to Reproduce:
!minimal? ( || ( net-libs/xulrunner net-libs/xulrunner-bin www-client/mozilla-firefox www-client/seamonkey www-client/seamonkey-bin ) ) ) You can choose between those.
From acroread-9.1.3.ebuild: x86? ( ... !minimal? ( || ( net-libs/xulrunner net-libs/xulrunner-bin www-client/mozilla-firefox www-client/seamonkey www-client/seamonkey-bin ) ) ) amd64? (... !minimal? ( || ( net-libs/xulrunner-bin www-client/seamonkey-bin ) ) )" I can choose non-binary packages on x86, but not on amd64. But I changed the dependency to net-libs/xulrunner on amd64 and it worked. Please add at least net-libs/xulrunner in the amd64 conditional.
Sorry my fault, assigning to maintainer, but I would think that there is a reason for that.
(In reply to comment #3) > Sorry my fault, assigning to maintainer, but I would think that there is a > reason for that. > Isn't acroread still 32-bit ?
(In reply to comment #4) > > Isn't acroread still 32-bit ? > Yes, the acroread binary is 32-bit. But still, I don't need xulrunner-bin. Here is the scenario, on ~amd64. 1. I install www-client/mozilla-firefox (the source package). As a dependency, it brings net-libs/xulrunner (the source package also). 2. I install app-text/acroread, and, maybe that's important, with USE="-nsplugin". As a dependency, it wants to bring net-libs/xulrunner-bin (the binary package). I don't really want to have 2 versions of this huge package installed. 3. I edit the acroread ebuild so it accepts the source xulrunner package. It installs, and the acroread standalone application works. Maybe it would crash as a browser plugin, I don't know, but I don't care since I disabled that.
This looks invalid to me, look at: http://bugs.gentoo.org/show_bug.cgi?id=206554#c4 for the reasons :-)
OK with closing this per previous comment?
(In reply to comment #7) > OK with closing this per previous comment? Yes, thanks Pacho! libgtkembedmoz.so isn't needed for a working browser plugin (USE="nsplugin" doesn't pull in the deps), but instead it was needed to display the help files shipped with previous adobe reader versions and probably is still needed for displaying html stuff inside the reader. I have no evidence here, but that is what the description states (Adobe Reader -> Options -> Internet). Resolving as invalid since the deps are/were fine and in the meantime xulrunner-bin/seamonkey-bin are gone from the tree, the deps in the ebuild were removed, and we don't even have a single 32bit -bin package left providing libgtkembedmoz.so on amd64. I'll add a testing version which removes the minimal USE flag and the deps alltogether on 32bit as well.
