This bug is a spawn from Bug 29855. Basically if mozilla isn't installed, then there is no nss entry for pkgconfig. Some apps, namely gaim, use pkgconfig to determine if nss is available. Since dev-libs/nss doesn't add a pkgconfig entry, gaim won't pick it up. Spoke with liquidx and brad[] about it in #gentoo-dev and they were hashing out ideas about how mozilla itself might need changing to use --with-system-nspr or something. Reproducible: Always Steps to Reproduce:
What are your thoughts on having dev-libs/nss provide a /etc/env.d file so that the nss libs would be read AHEAD of mozilla libs in /etc/ld.so.conf? Right now I have an issue with gaim where if mozilla is installed, mozilla's nss libs are being used regardless of how I configure gaim. The problem is that mozilla 1.6b's nss libs crash gaim-encryption, so I want it to use standalone nss instead but nothing I can do.
IMHO, that seems like a crufty workaround for a bug in a beta version of some software. If anything, the gaim ebuild should check for the mozilla USE flag and 1.6b and, if the user wants gaim-encryption, stop with a descriptive error message explaining the situation. Additionally, the gaim-encryption project should be made aware of this issue, if they aren't already. In an ideal world, Mozilla would provide a means to specify the usage of a separate nss library, like the --with-system-nspr flag. For some obscure reason, the Mozilla devs haven't deigned to implement that, despite prodding by users and packagers. Heck, Redhat deals with the packaging issue by building a full install from the tarball and then splitting the binary libraries into their component RPMs.
why die if mozilla sucks ? just have it use the independent library if it exists and fallback to mozilla if it doesnt
Currently, there isn't an autoconf macro to handle the detection of nss vs. mozilla-provided nss and set the include and libs paths accordingly. Without that type of macro, different developers make different assumptions about where nss will be. Of course, Mozilla.org doesn't make it any easier when they dump the same lib into two different paths. Since there isn't any autoconf setup, ebuilds need to provide the detection logic to setup the paths correctly. An example is the gaim ebuild, where the mozilla USE flag will cause a dependency upon net-www/mozilla, rather than dev-libs/nss. Portage's DEPEND || clause logic is broken, such that a preference for dev-libs/nss over net-www/mozilla is taken to mean that dev-libs/nss must be installed. What it should do is: See if any of the desired packages are installed, and only if they aren't should it force the preferred package.
spanky how do you propose I do that? My problem is that as long as mozilla is installed, gaim and gaim-encryption will see those libs first and link against them at run time.
FYI if I remove /usr/lib/mozilla from /etc/ld.so.conf, or if I add /usr/lib to /etc/ld.so.conf ahead of /usr/lib/mozilla, and then run ldconfig, gaim will startup fine, using the standalone nss libs. brad[] mentioned in #gentoo-dev not putting the mozilla line in there since he wasn't sure if it was used or not by anything.
I was having this same problem with the NSPR and NSS. My workaround was to manually grab the mozilla-nss.pc and the mozilla-nspr.pc file, then drop them into /usr/lib/pkgconfig. Probably not the most elegant workaround, but it allowed me to compile GAIM, and hasn't proven unstable thus far. Perhaps these two files should be installed by the dev-libs/nss and dev-libs/nspr ebuilds if Mozilla isn't already installed?
My work around in gaim and gaim-encryption is this: DEPEND="|| ( dev-libs/nss net-www/mozilla )" This syntax has once again been cleared for use in portage. Perhaps this bug is a non-issue for now?
It sounds like this bug is a no-op, except for the fact that I would like to remove the mozilla entries from /etc/ld.so.conf...
Yes and actually now since mozilla-firefox ALSO provides NSS and in yet ANOTHER location, I'm just going to depend solely on the standalone dev-libs/nss package. I think the evolution people are considering doing the same.
Game over, this isn't going anywhere, mozilla is being removed and no comment here for 2 1/2 years. (In reply to comment #10) > I'm just going to depend solely on the standalone dev-libs/nss > package. I think the evolution people are considering doing the same. evolution has been using dev-libs/{nss,nspr} since December 2005, see changelog.
