I downloaded SeaMonkey from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-07-19-09-trunk/seamonkey-1.0a.en-US.linux-i686.tar.gz, decompressed it and tried to start it: [07:57:25 vz6tml@exp01:~/Programme/seamonkey] $ ./seamonkey run-mozilla.sh: Cannot execute /usr/lib/mozilla/seamonkey-bin. Reson for this: [07:57:52 vz6tml@exp01:~/Programme/seamonkey] $ echo $MOZILLA_FIVE_HOME /usr/lib/mozilla Reason for this: [07:57:49 vz6tml@exp01:~/Programme/seamonkey] $ cat /etc/env.d/10mozilla LDPATH=/usr/lib/mozilla MOZILLA_FIVE_HOME=/usr/lib/mozilla CONFIG_PROTECT=/usr/lib/mozilla/defaults/pref [07:56:51 vz6tml@exp01:~/Programme/seamonkey] $ epm -qf /etc/env.d/10mozilla mozilla-1.7.8-r1 The same error happens when I try to start a "plain" Firefox, Mozilla Suite, Thunderbird or NVU. This is because they are NOT installed in $MOZILLA_FIVE_HOME but some place else ($HOME/Programme/{seamonkey,firefox,...}). Sure, I can easily unset MOZILLA_FIVE_HOME before starting what I want. But I do think that this is not a good idea, because that setting is "only" there because of the distribution. Such a system setting should (if possible) not have an effect on a normal user environment.
This is not an issue with latest version of mozilla-launcher ... I will talk with agriffis in morning I do not believe we will do anything with this until we get ready to add seamonkey to portage, I could be wrong.
(In reply to comment #1) > This is not an issue with latest version of mozilla-launcher ... Of course not, since mozilla-launcher is a "Gentoo application", so to speak. The issue is, that "distribution" settings (like the MOZILLA_FIVE_HOME environment variable) are "leaking" into the user environment and create an issue there. Nothing, but the "Gentoo applications" (like Firefox, Suite, ...) need that environment variable. Because of that, the env var should NOT be set in the env but read by the "Gentoo applications" whenever they require it. IOW: Please remove /etc/env.d/10mozilla. Further, this bug is *NOT* about Seamonkey. It is about the fact, that the environment variable MOZILLA_FIVE_HOME is set and causing problems. Seamonkey was an example. Nvu, Firefox, Suite, Thunderbird all behave the same.
(In reply to comment #0) > [07:57:49 vz6tml@exp01:~/Programme/seamonkey] $ cat /etc/env.d/10mozilla > LDPATH=/usr/lib/mozilla > MOZILLA_FIVE_HOME=/usr/lib/mozilla > CONFIG_PROTECT=/usr/lib/mozilla/defaults/pref I agree, at least MOZILLA_FIVE_HOME should be removed, and honestly I think that the CONFIG_PROTECT line should go away too. The LDPATH line might need to stay for the sake of applications that link against mozilla libraries. Let me talk this over with a couple of the other mozilla devs to make sure I'm not missing anything, otherwise I'll make this change ASAP.
I think there should be config-mozilla, which should copy as java-config the environment-file to the /etc/env.d from /etc/env.d/mozilla, because now galeon, epiphany are also b0rked from the missing ot incorrect MOZILLA_FIVE_DIR and in case of change to the default mozilla - this should rebuild all the packages, which are compiled against the current, the LD_PATH is also not correct, because now the two paths are defined and which comes first is used - which is very serious bug So in summary the user installs firefox and all is ok, the packages are built against firefox, after that installs mozilla and changes with the tool to mozilla, (env.d are copied) then all would have to be rebuild against mozilla (epiphany, galeon on so on) and so on.
And for things like seamonkey (which links explicitely to mozilla), there should be a wrapper which starts the application (setting the ldpath and motilla_five-home)
nevermind my comments, it is a bug in mozilla-firefox, mozilla-ebuilds and not directly in /etc/env.d, see my last comment on bug 100008. But one thing remains, I think the LDPATH should be removed, because all correctly linked applications, should have rpath/runpath in the dynamic section and should find the corresponding libraries, and no one could say to which library will incorrectly linked application link at run-time if both mozilla and mozilla-firefox ldpaths stay.
per Anarchy: Firefox set it via stubbs since we include our path we have dropped env.d/${module}
