This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 237389 - Yelp is not available in 32-bit for x86_64
Yelp is not available in 32-bit for x86_64
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-21 14:52 EDT by David Zeuthen
Modified: 2014-03-16 23:06 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-23 12:50:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Zeuthen 2007-04-21 14:52:45 EDT
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.
Comment 1 Jeremy Katz 2007-04-23 12:01:16 EDT
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
Comment 2 David Zeuthen 2007-04-23 12:44:02 EDT
(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.
Comment 3 Jeremy Katz 2007-04-23 12:50:15 EDT
(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. 
Comment 4 David Zeuthen 2007-04-23 13:04:47 EDT
(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 :-)
Comment 5 Christopher Aillon 2007-04-23 13:11:12 EDT
(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.
Comment 6 David Zeuthen 2007-04-23 13:23:44 EDT
(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.
Comment 7 Christopher Aillon 2007-04-23 13:30:01 EDT
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.
Comment 8 David Zeuthen 2007-04-23 13:45:09 EDT
(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.
Comment 9 Christopher Aillon 2007-04-23 13:56:06 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.