FC5T2 and Development issues, observations, and questions

[Nathan Grennan]

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.