Evolution-1.4 seems to requre net-www/mozilla when using the mozilla USE variable even though net-www/mozilla-firebird is installed. Now I tried creating a symlink from /usr/bin/mozilla to /usr/lib/MozillaFirebird/MozillaFirebird, but it seems as though Evolution isn't calling mozilla using any remote commands to open a new window (ie. /usr/bin/mozilla -remote "openURL(http://gentoo.com,new-window)"), but rather "mozilla <URL_CLICKED>". This isn't a very good work around because if you have a MozillaFirebird window open, you will be prompted to select a profile. I have not been able to test if mozilla will open correctly on machines with net-www/mozilla installed. Just to clarify, the *issue* I'm reporting is Evolution requires net-www/mozilla to be installed even when net-www/mozilla-firebird is installed Let me know if you need any more info from my end. :-) Best Regards,
Okay, I forgot one of the most important things before reporting a bug... check the forums. I checked and it seems that Evolution reads the info from gnome which you can set using gnome-control-center. Now, can we get Evolution-1.4 to build using net-www/mozilla-firebird?
if they overlap, then probably we should have a virtual/mozilla or something along those lines. does mozilla-firebird install its libs in a different directory? (eg. not /usr/lib/mozilla )
Itś installed under /usr/lib/MozillaFirebird and the binaries are named MozillaFirebird instead of mozilla. A symlink of /usr/lib/mozilla/mozilla to /usr/lib/MozillaFirebird/MozillaFirebird will work though.
related to http://bugs.gentoo.org/show_bug.cgi?id=20258 , where a guy asks if phoenix could fulfill mozilla deps?
Can't evolution just depend on dev-libs/nspr?
good point about nspr. i never looked into that.
well, i just looked into using nspr. we'll also need nss in portage for that to work: ftp://ftp.mozilla.org/pub/security/nss/releases/NSS_3_8_RTM/src http://www.mozilla.org/projects/security/pki/nss/ as for compiling with mozilla firebird, if it has nss/nspr libraries and include files, then it should just be a matter of changing the deps on evolution to do mozilla? ( || ( net-www/mozilla net-www/mozilla-firebird ) ) : ( net-libs/openssl ) and then finding a good way to choose between MOZILLA_FIVE_HOME or /usr/lib/MozillaFirebird.
I need both NSPR and NSS for the new gaim-encryption plugin. I'll see if I can figure out how the hell to compile NSS and put an ebuild up for it. Perhaps the summary if this bug should be changed to a request for the NSS ebuild?
I downloaded the NSS code and untar'd it in hopes of helping create an ebuild, but the source contained a bunch of directories, most of them containing source code, so I wasn't sure what needed to be compiled. I did some searching in the Mozilla newsgroups and on Google and I really couldn't find anything regarding compiling NSS outside of compiling Mozilla. After reading a couple of post, I'm starting to wonder if it was possible to compile NSS outside the Mozilla sources; If this is true, we're back in the same boat we were in before; how do we differentiate between the mozilla and MozillaFirebird ebuilds.
well, mozillafirebird cannot be used to compile evolution against it because it is missing the include files. At least the one in stable is. anyway, i've got nss and nspr in portage working with evolution 1.4.3, which will be the version that uses these libraries instead of the mozilla one. the reasoning is that they are much smaller and faster to compile. i'm battling whether to put mozilla also as an optional dep so it would be something like: || ( ( dev-libs/nspr dev-libs/nss ) net-www/mozilla ) the problem with this approach, is that it will extraneously install nss/nspr if mozilla is requested down the line. but the advantage is that it would use mozilla if it is already installed rather than add another two packages. then all we need is some extra logic to select whether mozilla is installed or not. this seems like the right way to go, albeit a little indeterministic.
As I noted in 23784, what about adding a virtual/nss and virtual/nspr and changing net-www/mozilla, dev-libs/nss, and dev-libs/nspr to provide the respective virtuals? Mozilla-Firebird is a separate issue and, since it's a work-in-progress, I'd vote for waiting until 0.7, rather than kludging the include files onto it. The other possibility I suggested in 23784 was to munge net-www/mozilla and mozilla-firebird to utilize dev-libs/nss and dev-libs/nspr, but that will require some non-trivial makefile hacking.
They actually have --use-system-nspr options, but that's tricky business. Mozilla developers may not use the same nspr in mozilla itself as is present in portage.
In that case, if the gentoo devs who handle the mozilla.org related ebuilds feel up to it, the ebuilds for nss and nspr could track the net-www/mozilla libraries. I haven't checked the sourcetree, so this could be a bear of a problem.
Created attachment 14848 [details, diff] mozilla-1.4.diff This patch modifies the mozilla 1.4 ebuild to add PROVIDE line denoting that mozilla 1.4 provides virtual/nss and virtual/nspr. The virtuals file(s) in the appropriate profile(s) need the following lines added: virtual/nss dev-libs/nss virtual/nspr dev-libs/nspr
Created attachment 14849 [details, diff] evolution-1.4.3.diff This patch changes the evolution ebuild to use the virtual/nss and virtual/nspr packages in leiu of always needing dev-libs/nss and dev-libs/nspr to be installed.
In addition to patches 14848 and 14849, the following changes should be made: - dev-libs/nspr should be modified to provide virtual/nspr - dev-libs/nss should be modified to provide virtual/nss. I'd leave its dependency on dev-libs/nspr, instead of changing it to the virtual, since mozilla, mozilla-firebird, and mozilla-thunderbird all provide both virtuals. - net-www/mozilla-firebird and net-mail/mozilla-thunderbird should be modified to provide both virtual/nss and virtual/nspr. I can create and attach diff files for all of the aforementioned changes, but they're all one-liners so I elected to describe them instead. The virtual package functionality should be expanded to include versions on the package names, but that is a matter for another bug.
the problem is just PROVIDE'ing virtual/nss and nspr won't do much unless they all install nspr/nss in the same location. otherwise, we'll still have to have some ugly code to detect which nss/nspr to use.
I ran into the issue with the latest gaim ebuild, which now needs nss for the encryption plugin. I modified the ebuild to incorporate a check for mozilla and, based on that, modify the --with-nss-libs and --with-nspr-libs autoconf flags. Ideally, there should be an m4 autoconf macro to detect where nss/nspr are installed.
So... We can't PROVIDE virtual/nss and virtual/nspr because the mozilla and mozilla-firefox packages install them to different locations. We can't install mozilla and mozilla-firefox to the same location because we can't have two packages owning the same set of files. We don't want to modify every ebuild needing nss/nspr to test for mozilla/mozilla-firefox include locations because that would be a pain in the neck, particularly if it changes. It sounds to me like the only real solution is to have separate nss/nspr ebuilds which provide those libraries to evolution and everybody else. (Which reminds me, who else uses these libraries?) The only exceptions are packages that provide their own nss/nspr, such as mozilla and mozilla-firefox. Does this sound right? The downside is that evolution will pull in nss/nspr even if mozilla is installed, but I dislike liquidx's suggestion in comment 10. The libraries surrounding mozilla are problematic enough without injecting that kind of randomness into the bug reports... ;-)
You realize that there already ARE separate standalone nss and nspr packages, right? For the record gaim and gaim-encryption use NSS and NSPR.
I think that any solution created at the distro level will be a hack. The real solution is to kick this upstream to mozilla.org. Then people need to beat them over the head until they use the separate NSS and NSPR packages in all mozilla.org projects. The most elegant solution in gentoo is, IMHO, the one implemented in the gaim ebuild. It doesn't handle the three-way selection between dev-libs/nss, net-www/mozilla, and net-www/mozilla-firefox, but it at least handles the first two.
Okay, gaim is already doing this (using standalone nss/nspr). I guess that evolution should be modified to do the same thing, right? Or does evolution need more from mozilla than just those libraries?
agriffis, i believe evolution already did that .. this bug is talking about whether it is possible to make net-www/mozilla* to provide virtual/nss virtual/nspr. the answer is probably that it is not possible in the way nss/nspr is handled by mozilla.org
Liquidx, sounds like you missed my comment #19 Regarding evolution, I think it would be better to rely on nss/nspr ebuilds in all cases, instead of allowing reliance on mozilla. That would result in more defined behavior, especially since there are so many moz flavors (moz, moz-bin, firefox, firefox-bin, thunderbird, thunderbird-bin) Same is true for gaim. Both evo and gaim right now have custom code to find nss/nspr libraries. The only other way I see to do this is to have an nss.eclass that knows all the places it can fetch the nss libs, and an nspr.eclass to do similarly. That would allow RDEPEND settings in one place that would work for evo, gaim, etc.
Aron has a good point. i'd say that nss and nspr are quite small compared to mozilla that users shouldn't worry too much about depending on that even if moz and firefox are installed. i'll do that in the next revision or in the 1.5 series. so i'm just marking this bug as wontfix.
