Description of problem: The problem is, Firefox.x86_64 has nearly no plugins available. But he conflicts at /usr/bin/firefox with firefox.i386. So if you don't want an conflict in your rpm-database you should choose one of them. But I would test both at my web applikations. Version-Release number of selected component (if applicable): all until yet (4test1) Actual results: Only one could cleanly be installed Expected results: A rpm should exist were both are awailable so that /usr/bin/firefox and may be called /usr/bin/firefox64 exists. And both pakages called above are mixed in. Other way use alternatives and let the real binary stay at /usr/lib and /usr/lib64 so no rpm conflict does exists. Okay as third the /usr/bin64 discussion still exists...
I guess one or the other would be an OK choice. At present, only 64-bit version is provided, which isn't very useful if one wants to run Flash, Java or something else. The only choice is to pull i386 package from i386 version of FC. Not convenient... BTW, this bug should be attached to the devel tree, as this is where the situation still exists.
Even if the conflict is resolved in the firefox script, it would be nice to have some way for users to choose which version of firefox to run, such that you could install both firefox.x86_64 and firefox.i386 side by side. The current script simply tests for /usr/lib64 and uses that if it's present, but this is clearly far from ideal if you get past the install conflicts and want to run the 32-bit firefox. Incidentally, yum will not install one firefox arch if the other it installed, but rather replace one with the other, whereas rpm has no problem installing them both in parallel. Presumably this has to do with the conflicts in /usr/bin/firefox. I haven't tried to get yum to install both at the same time yet. The other negative point is that firefox.i386 and its deps are not in the x86_64 distro, so, in order to get them installed and kept up-to-date, one has to add the entire i386 channels to the collection of repositories yum or up2date use. Ideally, they'd be included in the x86_64 repositories, for a mere extra 13MB.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Distribution against which this bug was reported is no longer supported; could you please reproduce this with the updated version of the currently supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. Thanks in advance.
We haven't got any reply to the last question about reproducability of the bug with Fedora Core 6, Fedora 7, or Fedora devel. Mass closing this bug, so if you have new information that would help us fix this bug, please reopen it with the additional information.