Description of problem: Trying to run a system on x86_64 with only a firefox.i386 package (e.g. no firefox.x86_64 installed). However, yelp is not available in 32-bit; that's probably a bug. Notably devhelp is. Alternatively, firefox could (and perhaps should but I dunno the specifics) be split into firefox + firefox-libs so I could get away with just having 64-bit firefox-libs installed. Btw, if I have both firefox.i386 and firefox.x86_64 installed how do I configure which one to launch by default? Shouldn't this be a blocker? Thanks.
yelp doesn't provide any sort of API/ABI and thus isn't a multilib package really. Why do you care which archness of firefox that you're running? I suspect your answer is the flash plugin, but the 32bit firefox isn't going to work with open source plugins that we ship like the totem one. The real right thing to do here is to beat nspluginwrapper into shape so that plugins are run out of process
(In reply to comment #1) > Why do you care which archness of firefox that you're running? I suspect your > answer is the flash plugin, Correct. I'm really trying to make 64-bit work for me... but at this rate I suspect I'm going back to 32-bit pretty soon :-) > but the 32bit firefox isn't going to work with open > source plugins that we ship like the totem one. Then by the same token, then the whole way we do multilib doesn't seem to make a lot of sense; I think what you want is the packaging laws to mandate that all non-private shared libraries (and binaries required by said libraries) _must_ be in <pkgname>-libs and only then make *-libs packages available for the secondary arch as well. As a side-effect, the user will never end up with binaries for the secondary arch _unless_ he installs an RPM that is specifically tagged for being available for the secondary arch (e.g. OO.o in the past when e.g. x86_64 didn't work) - or installed some binary crap that only is available on the secondary arch (e.g. Adobe Reader). Notably the former may pull in secondary arch runtime dependencies but we should be able to cope with that; e.g. pulling in the right RPMS at compose time etc. etc. etc. > The real right thing to do here > is to beat nspluginwrapper into shape so that plugins are run out of process No disagreement there. What's the bug number for that? Btw, if someone knows, I'd still love to know how to configure firefox such that /usr/bin/firefox selects the browser that I want to use; e.g. 32- or 64-bit. Is there a configuration file somewhere? Maybe I should file that in another bug.
(In reply to comment #2) > (In reply to comment #1) > > but the 32bit firefox isn't going to work with open > > source plugins that we ship like the totem one. > > Then by the same token, then the whole way we do multilib doesn't seem to make a > lot of sense; I think what you want is the packaging laws to mandate that all > non-private shared libraries (and binaries required by said libraries) _must_ > be in <pkgname>-libs and only then make *-libs packages available for the > secondary arch as well. This is essentially what we do. But with the _advantage_ of not requiring all of the manual work on the part of the packager and the additional repo bloat that would be caused by having roughly a third more packages in the repository (and the number of packages in the repository _is_ a big deal... when we move to presto-ifying everything, the metadata download can in a lot of cases be more than what you have to download as far as packages!) > As a side-effect, the user will never end up with binaries for the secondary > arch _unless_ he installs an RPM that is specifically tagged for being > available for the secondary arch (e.g. OO.o in the past when e.g. x86_64 didn't > work) - or installed some binary crap that only is available on the secondary > arch (e.g. Adobe Reader). Notably the former may pull in secondary arch runtime > dependencies but we should be able to cope with that; e.g. pulling in the right > RPMS at compose time etc. etc. etc. Yep, you've described how things work quite nicely :-) > > The real right thing to do here > > is to beat nspluginwrapper into shape so that plugins are run out of process > > No disagreement there. What's the bug number for that? Not sure off-hand... I do know that there is one. > Btw, if someone knows, I'd still love to know how to configure firefox such that > /usr/bin/firefox selects the browser that I want to use; e.g. 32- or 64-bit. Is > there a configuration file somewhere? Maybe I should file that in another bug. There is a bit of a hack that can be done. Warren has the details.
(In reply to comment #3) > This is essentially what we do. But with the _advantage_ of not requiring all > of the manual work on the part of the packager and the additional repo bloat > that would be caused by having roughly a third more packages in the repository So you're arguing that not having -libs packages is a good thing. Instead we now look at whether we have a -devel subpackage. I think we've seen, just in the past few months, how this doesn't work though... (just two of my packages (HAL and CK) recently grown -libs packages just because "otherwise it won't work with multilib" or so I was told). Anyway, I believe Firefox is in the same camp... We _wrongfully_ advertise a 32-bit firefox on x86_64 well knowing that it will never work with e.g. the Totem plug-in. Don't you think this is _wrong_? Morale: multilib pkg detection should move from -devel -> -libs. > (and the number of packages in the repository _is_ a big deal... when we move to > presto-ifying everything, the metadata download can in a lot of cases be more > than what you have to download as far as packages!) Devils advocate: Our tools need to scale anyway since the number of packages will only keep growing. (corollary: something about that sometimes it's good to force extremes if you want to force people to resolve fundamental problems) But I guess I'm just ranting at this point :-) .... Well, what I've learned is that I shouldn't run 32-bit Firefox on Fedora. Guess I can delete all the 32-bit RPMS on my 64-bit system now :-)
(In reply to comment #4) > Anyway, I believe Firefox is in the same camp... We _wrongfully_ advertise a > 32-bit firefox on x86_64 well knowing that it will never work with e.g. the > Totem plug-in. Don't you think this is _wrong_? Who is this _we_? I _never_ advocate using the 32bit firefox on a 64bit stack. Otherwise, I might have actually listened to all the people that wanted me to add some configuration thing to switch between them. Which you should appreciate is something that the user should never have to decide between. I'm rather surprised to see you are arguing for this.
(In reply to comment #5) > (In reply to comment #4) > > Anyway, I believe Firefox is in the same camp... We _wrongfully_ advertise a > > 32-bit firefox on x86_64 well knowing that it will never work with e.g. the > > Totem plug-in. Don't you think this is _wrong_? > > Who is this _we_? The Fedora Project. We offer a 32-bit firefox package on x86_64. How is this not saying "you can use 32-bit firefox"? > I _never_ advocate using the 32bit firefox on a 64bit stack. > Otherwise, I might have actually listened to all the people that wanted me to > add some configuration thing to switch between them. Which you should > appreciate is something that the user should never have to decide between. Uh, I'm saying too it's non-sense to offer a 32-bit firefox package; it does makes a lot of sense to offer a 32-bit firefox-libs if, and only if, it makes sense to have 3rd party 32-bit apps on x86_64 using it. Which maybe, you know, just not may be the case especially since, uh, Firefox is not exactly ABI stable. Correct? > I'm rather surprised to see you are arguing for this. I think you misunderstood me.
You want xulrunner then. I'd pop in an RPM now into rawhide, but the whole freeze thing. I really do wish that we'd simply branch for F7 already so F8 dev could start.
(In reply to comment #7) > You want xulrunner then. Well, yes and no. The problem is much more fundamental than just firefox; e.g. I think I've argued that the heuristic "pkg is multilib iff it got a -devel subpackage" is broken; instead we should use "pkg is multilib iff (is explicitly tagged as multilib) OR (pkg has a name ending in -libs)". And then we make the laws of packaging reflect this and maintainers start fixing their packages. The fix is hard too: it involves creating tons of -libs sub-packages. So I can understand that some people don't want to do that; it's way too invasive and may highlight other deficiencies / problems we already have. Shrug. So it's like this: Firefox is just an example of where we have this problem. Guess I've been picking on Firefox a lot lately; nothing personal. > I really do wish that we'd simply branch for F7 already so F8 dev > could start. Me too! But that's a separate thing.
(In reply to comment #8) > I think I've argued that the heuristic "pkg is multilib iff it got a -devel > subpackage" is broken; Agreed. I've already argued this elsewhere. The answer is "come up with something better." > instead we should use "pkg is multilib iff (is explicitly > tagged as multilib) OR (pkg has a name ending in -libs)". How do we do the first without forcing each package maintainer to essentially keep track of the dependency chains below and/or above them. Not sure the second is a good idea either because names are never good enough to go on IMO. Maybe the metric we could use is installing .so files directly under $libdir (firefox would thus be excluded as it's packages are a few subdirectories under $libdir) would be slightly better, but I haven't given it too much thought. The short answer is I stopped caring because this isn't going to be fixed for F7, and in F8 we will have xulrunner.