On Fri, 2006-11-10 at 16:17 +0200, Gilboa Davara wrote: > The attached patch (which should cover all 64bit arches) enable you to > start the 32bit version of firefox (if it's installed) by starting > firefox with the "--32" command line option. > > Before I submit this to bugzilla, I have two questions: > > - Do we rather have a single firefox script that executes both 32bit and > 64bit or do we want to break the it to dedicated firefox[64] and > firefox32 scripts. Please make sure it defaults to 32-bit firefox on ppc64, just like most of the rest of userspace does (including the Java and RealPlayer plugins). If you _really_ want ppc64 firefox, you should need to run with '--64' to get it.

Gilboa Davara wrote: > Hello all, > > The attached patch (which should cover all 64bit arches) enable you to > start the 32bit version of firefox (if it's installed) by starting > firefox with the "--32" command line option. > > Before I submit this to bugzilla, I have two questions: > > - Do we rather have a single firefox script that executes both 32bit and > 64bit or do we want to break the it to dedicated firefox[64] and > firefox32 scripts. > - Where should I submit this patch? Mozilla or redhat? > > - Gilboa https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214100 I wrote an alternative implementation in this bug. I don't fully agree with the rejection of this, but I do agree that the best long-term solution is to fix nspluginwrapper to offload *ALL* plugins to a separate process. A separate process also allows greater security control with selinux. Logic of my Implementation: * If only the /usr/lib browser is installed, run it. * If only the /usr/lib64 browser is installed, run it. * If both are installed, run /usr/lib64 unless it is overridden in /etc/sysconfig/firefox-arch. * Allow editing /etc/sysconfig/firefox-arch as the official means for the system administrator to override their arch selection. %config(noreplace) %{_sysconfdir}/sysconfig/firefox-arch This is necessary in the %files section of firefox.spec. Benefits of this approach: 1) This DOES NOT CHANGE the behavior from its current default, which works with browsers shipped on x86_64. 2) This defines an explicit way for the system administrator to override their arch selection in a way that wont break with future package updates. This effectively enables CHOICE.

Gilboa Davara wrote: > > This a nice solution - though I rather have a simple method of > overriding the selection without editing a configuration file and/or > making it system wide. > IMHO, adding a command line parameters seems like the obvious choice as > it gives the user additional means of controlling which version is > executed. > > I can combine your patch with mine - read, use the default > in /etc/sysconfig/firefox-arch unless the user specifically requested > something else. > Does it sound reasonable to you? > > - Gilboa I don't think there is much value to end-users to have a --32 or --64 switch, because command line is NOT how you should expect users to launch firefox. It wouldn't hurt to have the option though.

Also keep in mind that due to xremote, you CAN'T run both 32bit and 64bit browsers at the same time without making further modifications to firefox to handle it.

In any case, merging our patches would be a moot point, because it wont be accepted into Fedora.

Gilboa Davara wrote: >> In any case, merging our patches would be a moot point, because it wont >> be accepted into Fedora. > > Point taken. > > ...One question though, if there's no way to use it (32bit firefox), why > the !@?#^?#^ are we installing it in the first place? > > - Gilboa > I'm pretty annoyed by this as well. So I am soon submitting an alternative short-term solution to Extras. The real solution is to make browser plugins run out-of-process. This would have tremendous benefits to us in the long-term. I am skeptical however that it will happen in a timely manner.

Gilboa Davara wrote: >> I'm pretty annoyed by this as well. So I am soon submitting an >> alternative short-term solution to Extras. >> >> The real solution is to make browser plugins run out-of-process. This >> would have tremendous benefits to us in the long-term. I am skeptical >> however that it will happen in a timely manner. >> > > You thinking about submitting nspluginwrapper? > > - Gilboa > No. It is broken and requires lots of work. You will see my submission soon. Warren Togami wtogami(a)redhat.com

Warren Togami wrote: > Gilboa Davara wrote: >>> I'm pretty annoyed by this as well. So I am soon submitting an >>> alternative short-term solution to Extras. >>> >>> The real solution is to make browser plugins run out-of-process. >>> This would have tremendous benefits to us in the long-term. I am >>> skeptical however that it will happen in a timely manner. >>> >> >> You thinking about submitting nspluginwrapper? >> >> - Gilboa >> > > No. It is broken and requires lots of work. You will see my submission > soon. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215256 Yes, this really sucks.

Can you think of a way to make a firefox.i386 dependency specifically if this is a x86_64 arch package?  I can't.

Jesse Keating wrote: > On Monday 13 November 2006 00:37, Warren Togami wrote: >> Can you think of a way to make a firefox.i386 dependency specifically if >> this is a x86_64 arch package? I can't. > > Have file requires on one of the 32bit libraries. Only the 32bit > firefox would supply that library. > > This doesn't exactly work in the case of firefox, because it uses versioned directories. And AFAIK none of the other things owned by the package is unique to firefox.i386. Warren Togami wtogami(a)redhat.com

Jesse Keating wrote: > Have file requires on one of the 32bit libraries. Only the 32bit firefox > would supply that library. This doesn't exactly work in the case of firefox, because it uses versioned directories.