[ATrpms-users] Re: mplayer win32codecs or firefox flash plugin on x86_64?

Tako Schotanus quintesse at palacio-cristal.com
Tue Nov 15 02:44:46 CET 2005


Axel Thimm wrote:

>On Tue, Nov 15, 2005 at 12:37:59AM +0100, Tako Schotanus wrote:
>  
>
>>Axel Thimm wrote:
>>    
>>
>>>On Mon, Nov 14, 2005 at 04:00:45PM +0100, Tako Schotanus wrote:
>>>      
>>>
>>>>Ok, I back to testing the installation of a x86_64 system with bits of 
>>>>i386 mixed in (like firefox for example).
>>>>
>>>>So what I did was after having installed smart + the medley package and 
>>>>after having upgraded was to _add_ the i386 version of each repository 
>>>>to smart's list of channels.
>>>>  
>>>>        
>>>>
>>>That's a bit too much. I would only pull the ones I really need, as
>>>random co-installs of applications like mplayer for 64 and 32 bits
>>>will not work as you would wish.
>>>
>>>      
>>>
>>I understand, but I want this to be as stupid as possible, I don't want 
>>to know, nor do I think should most users, which channels to add and 
>>which not. If in the end we could always just add all channels it might 
>>be something that could be installed as a special medley package maybe?
>>    
>>
>
>No, things may break more than that step would fix.
>
>  
>
>>>I think x86_64 wins.
>>>
>>>      
>>>
>>Which would be great for most cases! If the x86_64 version always wins 
>>we could safely leave the i386 repos in our channel list (that's what I 
>>hope anyway :-).
>>    
>>
>
>Imagine the following steps:
>
>install foo.32
>install foo.64
>uninstall foo.64
>
>You are left with a broken foo.32.
>
>So, no, placing 32 and 64 bit packages indiscriminately is asking for
>troubles.
>  
>
Ok, I might be a software engineer and I like fiddling with stuff, but 
most of the time my system should just work.  So all of this just 
suggests one thing to me: I'm not going to use x86_64. Period. I using 
smart just because I think all these things should be absolutely 
painless, in fact I started using Linux when I first found out that 
apt-get could be used to instal new packages without having to find and 
download a dozen other packages. So I not going to start again by 
figuring out specific combinations of channels and what to install and 
how etc. End of the line for me here :-)

>  
>
>>Ok, but doesn't that mean that the repo managers should provide 32 bit 
>>version for "problematic" packages? That would be fine with me... but 
>>more work for you because I'll start asking for 32 bit versions for 
>>several packages :-)
>>    
>>
>
>That would be the procedure, but I, as a repo maintainer, would not
>start mixing too much of 32 bits vs 64 bits, especially not non-ATrpms
>packages like firefox/java/etc.
>
>  
>
I understand, but these are exactly the ones I need (and I image a lot 
of others as well).

>>I haven't been able to rebuild the Java packages yet though, using 
>>"rpmbuild -ba --target=i586 java-1.5.0-sun.spec" does not seem to help 
>>as the spec file insists that it needs the amd64 version. Putting 
>>"linux32" in front of the rpmbuild command doesn't fool it either. And 
>>even commenting out all the "%if(n)arch x86_64" where they appear still 
>>doesn't help, because now they build ok but the result is still a bunch 
>>of x86_64 rpms!
>>
>>Any ideas on how to fix that?
>>    
>>
>
>You should rebuild in a clean 32 bit environment. This can be a chroot
>on your 64 bit system.
>  
>
Strange, these packages don't actually build any code, they just 
repackage the existing Sun files, it should be possible to do that 
without setting up a seperate 32 bit environment shouldn't it?

And how _do_ you go about setting up a clean 32 bit environment anyway? :-)

Cheers,
 -Tako




More information about the atrpms-users mailing list