[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FC5T2 and Development issues, observations, and questions

Alan Cox wrote:
think this could be problematic for debugging unless there is some boot option that makes the kernel act 100% like it would with a UP kernel.

Makes it easier - we've only got *one* kernel to debug now 8)
Not the cleanest logic
3. Where are the x86_64 Xen 3.0 kernels? All I see are i686 in

6. I wanted to install galeon.i386 from extras, and it needed to install mozilla.i386. Being that I am running x86_64, mozilla.x86_64 was already installed. For some reason mozilla.i386 refused to install, because it said /usr/bin/mozilla and /usr/share/man/man1/mozilla.1.gz conflicted with mozilla.x86_64. Both are mozilla-1.7.12-3. Is this a bug in the package? Is this a bug in rpm? I originally used yum and got the error, but then I tried rpm directly and received the same error message.

Correct behaviour. Its refusing to allow two clashing sets of files to overwrite
each other. You need to remove the x86_64 one first.
No, that isn't the correct behavior. It isn't the behavior of FC4. Though I don't happen to have mozilla.i386 and mozilla.x86_64 installed 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 the dominate one in the case where both are installed. If the mozilla behavior I describe is the new behavior then x86_64 systems just became a lot more problematic than they already are.

Example of why I need both. I need galeon.i386 instead of galeon.x86_64 for things like flash and java. Then for galeon.i386 I need 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 most likely other packages that have a much bigger list of packages that depend on them. Then I would have to start replacing huge chunks of the system with i386 packages just so I can use one i386 package.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]