Alan Cox wrote:
Its very much logical. One of the big problems with bugs is always reproducing
them and also testing kernels. If there are less kernels then the testing can
be more complete and cover all users better.
Logical from one perspective. I think I still have a point that the
ability to debug with UP kernels would still be useful.
on my FC4 desktop, I do have Gconf2.i386 and Gconf2.x86_64 installed on
my desktop. They didn't conflict with each other, and do contain
binarys. The rule as far as I know has been that the x86_64 binary is
They were designed to allow for this, most libraries and support daemons
are. The same isn't true the way applications are usually packaged. After
all if you type mozilla which one should run ?
This is true, I do have another problem with bonobo where galeon.i386
needs bonobo packages that are i386, and the rest of Gnome needs x86_64.
Both i386 and x86_64 get installed. But the bonobo program doesn't look
in /usr/lib for bonobo files, hence breaking galeon.i386. I workaround
this by symlinking the file needed from /usr/lib to /usr/lib64.
Technically the files can be arch dependent so this would not work in
all cases, but happens to work with galeon. From previous conversations
about this it is just bad design on the part of bonobo.
mozilla.i386. But then I need mozilla.x86_64 for beagle.x86_64. I could
replace beagle.x86_64 with beagle.i386, but beagle isn't the only thing
that depends on mozilla. yelp, devhelp, and mozilla-devel(and
mozilla-devel.x86_64 is the only sane version to install on a x86_64
system outside of a chroot). Plus this is just a minor example there are
The problem you are hiting is that mozilla the application and mozilla the
bits used by other programs are packaged in a way that makes it hard to have
both. Thats not rpm misbehaving or an error in the way the system functions.
It does appear, as you rightly point out, to be a problem for end users and
you should probably file a bug for that. It may be the packages need splitting
up so that beagle/etc can depend on mozilla-core-x8664 or similar and have
mozilla the application seperate.
I agree that this could be fixed by better packaging, or even better
mozilla. I don't see why mozilla is being blocked in this case. From
what I see, having just looked into it, is that /usr/bin/mozilla is a
script, and it uses paths that mention /usr/lib. The way I would expect
this to be handled would be that the mozilla.x86_64 package would
override the mozilla.i386's version of the script, and all should be
good. Maybe a better way would to rewrite the script to be conditional,
and realize if it was on a x86_64 system or not. Yet another way, which
was done with galeon was just get rid of the need for the script.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list