RE: [gentoo-dev] MOZILLA_FIVE_HOME

RE: [gentoo-dev] MOZILLA_FIVE_HOME

[Jeff Griffiths]

Hi Simon

sorry if terse translates to upset, that wasn't my intended 
tone. try confused? ...and typing at high speed.

yes the workaround is effective and my gentoo / Komodo user 
is now happy. what i'm really curious about is why gentoo 
mozilla does this in the first place - other mozillas tend 
not to PERMANENTLY set this var as it has the tendency to
interfere with other mozilla-based applications ( like 
Komodo ).

thanks

Jeff Griffiths
ActiveState Technical Support
http://www.ActiveState.com 

> -----Original Message-----
> From: Simon Reynolds [mailto:sproket@adelphia.net]
> Sent: Thursday, September 11, 2003 10:14 AM
> To: Jeff Griffiths
> Cc: Gentoo-Dev (E-mail)
> Subject: Re: [gentoo-dev] MOZILLA_FIVE_HOME
> 
> 
> On Thu, 2003-09-11 at 11:31, Jeff Griffiths wrote:
> > why is MOZILLA_FIVE_HOME permanently set in gentoo?
> >
> > why on gentoo is MOZILLA_FIVE_HOME permanently set? this 
> isn't set by
> > for example binaries from mozilla.org, which plays nice with Komodo
> > 
> > workaround is either:
> 
> > % unset MOZILLA_FIVE_HOME && komodo
> Continuing in the same vein as this work-around, you could move komodo
> off your path or rename it komodo.bin or some such and create a simple
> sh wrapper that unsets MOZILLA_FIVE_HOME and then runs the binary.
> 
> Considering that there are exist such simple and effective 
> work-arounds,
> I am really surprised by the highly upset tone of your email.
> 
> I hope this helps!
> ~Simon Reynolds
> 
> 

--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] MOZILLA_FIVE_HOME

[Simon Reynolds]

On Thu, 2003-09-11 at 15:38, Jeff Griffiths wrote:
> Hi Simon
> 
> sorry if terse translates to upset, that wasn't my intended 
> tone. try confused? ...and typing at high speed.
> 
My apologies for jumping to conclusions, that wasn't very mature of me.
> yes the workaround is effective and my gentoo / Komodo user 
> is now happy. what i'm really curious about is why gentoo 
> mozilla does this in the first place - other mozillas tend 
> not to PERMANENTLY set this var as it has the tendency to
> interfere with other mozilla-based applications ( like 
> Komodo ).
I don't know all the reasons, and I am not a developer. But from what I
can tell several older ebuilds still in the portage tree that depend on
mozilla like nautilus, galeon, evolution etc. use it to find where
mozilla is at for things like linking, etc. For the newest versions of
those packages, however, it is no longer being used. And up-to-date
versions of galeon, evolution and mozilla all seem to work fine without
it being set.


--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] MOZILLA_FIVE_HOME

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

On Thu, 2003-09-11 at 14:11, Simon Reynolds wrote:
> I don't know all the reasons, and I am not a developer. But from what I
> can tell several older ebuilds still in the portage tree that depend on
> mozilla like nautilus, galeon, evolution etc. use it to find where
> mozilla is at for things like linking, etc. For the newest versions of
> those packages, however, it is no longer being used. And up-to-date
> versions of galeon, evolution and mozilla all seem to work fine without
> it being set.

I think MOZILLA_FIVE_HOME may be used to allow things like evolution
find and link against the nss and nspr libs included with Mozilla. This
allows evolution to run using these libs rather than having to emerge
dev-libs/nss and dev-libs/nspr to get these libs in /usr/lib.

Again, I'm not a Mozilla expert, but I do know that evolution can and
will use Mozilla's nss and nspr if "mozilla" and "ssl" are set in USE.
Our evolution ebuild can also use stand-alone nss and nspr, or use
openssl to provide ssl support instead.

If setting MOZILLA_FIVE_HOME globally is done so that things like evo
can use the nss and nspr libs in /usr/lib/mozilla, and this messes other
apps up, it may be best to tweak apps like evolution so they simply use
the stand-alone nspr and nss. Then, in theory (this needs confirmation,)
the global MOZILLA_FIVE_HOME setting can (?) be safely removed from the
environment.

Best Regards,

Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-dev] MOZILLA_FIVE_HOME

[Jeff Griffiths]

> -----Original Message-----
> From: Daniel Robbins [mailto:drobbins@gentoo.org]
> Sent: Thursday, September 11, 2003 1:49 PM
> To: Simon Reynolds
> Cc: Jeff Griffiths; Gentoo-Dev (E-mail)
> Subject: RE: [gentoo-dev] MOZILLA_FIVE_HOME

> If setting MOZILLA_FIVE_HOME globally is done so that things like evo
> can use the nss and nspr libs in /usr/lib/mozilla, and this 
> messes other
> apps up, it may be best to tweak apps like evolution so they 
> simply use
> the stand-alone nspr and nss. Then, in theory (this needs 
> confirmation,)
> the global MOZILLA_FIVE_HOME setting can (?) be safely 
> removed from the
> environment.
> 
> Best Regards,
> 
> Daniel

okay thanks, that's starting to make a lot more sense. FYI, the 
solution of the Komodo dev team is to patch our mozilla to ignore 
this vars and any other vars mozilla might look at by default. we 
simply hadn't run into this situation until now, although googling 
for MOZILLA_FIVE_HOME reveals lots of other grief on mailing lists
 regarding different versions of mozilla-based software getting 
generally confused.

thanks again,

Jeff Griffiths
ActiveState Technical Support
http://www.ActiveState.com 

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] MOZILLA_FIVE_HOME

[Jeff Griffiths]

why is MOZILLA_FIVE_HOME permanently set in gentoo?

users trying to run gentoo mozilla and ActiveState Komodo cannot because
MOZILLA_FIVE_HOME is permanently set by gentoo mozilla - this
effectively breaks 3rd party / non-gentoo applications based on mozilla
(including mozilla.org's binaries)

why on gentoo is MOZILLA_FIVE_HOME permanently set? this isn't set by
for example binaries from mozilla.org, which plays nice with Komodo

workaround is either:

simple: unset MOZILLA_FIVE_HOME

( can't code and browse web at same time )

complex: create komodo-specific user without MOZILLA_FIVE_HOME set in
ENV, and su to that user to run komodo.

or just do this:

% unset MOZILLA_FIVE_HOME && komodo



Jeff Griffiths
ActiveState Technical Support
http://www.ActiveState.com 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] MOZILLA_FIVE_HOME

[Simon Reynolds]

On Thu, 2003-09-11 at 11:31, Jeff Griffiths wrote:
> why is MOZILLA_FIVE_HOME permanently set in gentoo?
>
> why on gentoo is MOZILLA_FIVE_HOME permanently set? this isn't set by
> for example binaries from mozilla.org, which plays nice with Komodo
> 
> workaround is either:

> % unset MOZILLA_FIVE_HOME && komodo
Continuing in the same vein as this work-around, you could move komodo
off your path or rename it komodo.bin or some such and create a simple
sh wrapper that unsets MOZILLA_FIVE_HOME and then runs the binary.

Considering that there are exist such simple and effective work-arounds,
I am really surprised by the highly upset tone of your email.

I hope this helps!
~Simon Reynolds


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] MOZILLA_FIVE_HOME

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Thu, 2003-09-11 at 11:14, Simon Reynolds wrote:
> Considering that there are exist such simple and effective work-arounds,
> I am really surprised by the highly upset tone of your email.

There's no way for you to know if he was upset or not. He asked a
question, explained a problem, and shared a workaround. Solving the root
problem is nearly always preferable to using a work-around.

If it breaks third-party binaries, including ones from mozilla.org, it's
probably a good idea to look into exactly why MOZILLA_FIVE_HOME is set,
and if it can be unset in a future version of the Mozilla ebuild.

I'm not a Mozilla expert and haven't looked into it, so I'm not sure.
Maybe some other devs can comment.

Best Regards,

Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]