Multiarch crazyiness

Hans de Goede j.w.r.degoede at hhs.nl
Mon Oct 22 14:46:52 UTC 2007


Richard W.M. Jones wrote:
> Jon Masters wrote:
>> It's still going to be the case that many people will want packages from
>> both, for a long time, and in some cases that makes more sense - it's
>> not always better to have 64-bit versions.
>>
>> For these reasons, I think a better solution is needed, and needed as a
>> matter of urgency. That solution should also be well documented, with
>> very obvious policy document(s) - not just mailing list posts - that
>> make it very easy for package maintainers to understand. It really is
>> time to fix this properly - can we get a working group setup?
> 
> My original question was to some extent taking the position of devil's 
> advocate.
> 
> But I think this is interesting: what are the actual choke-points which 
> cause ordinary Fedora users to need to use 32 bit libs & apps on their 
> 64 bit x86-64 machines?
> 
> Off the top of my head I could think of:
> 
>  - proprietary firefox plugins (could probably be handled using a 
> wrapper, in fact _should_ be handled using a wrapper because dlopening 
> binary-only plugins in your browser is stupid)
> 

I fully agree, but that wrapper needs 32 bits libraries both for its own 
plugin-loader part and to satisfy the deps of the plugin.

>  - proprietary 32 bit binaries (does Fedora care about them?)
> 

Well, we just fixed glibc to make googleearth work (although that was really a 
glibc bug), and I'm sure I can think of others like erm, matlab, maple, 
labview, picasse to name a few.

>  - free software with lots of 32 bit assumptions (OpenOffice used to be 
> like this, but IIRC they fixed it ... are there any others?)
> 
warzone2100 to name one, wine is another small player in this area.

> Perhaps it's just easier to fix this list of choke-points than to 
> implement working multiarch support?


32 bit is not going away, I share your wishes, but really it is not going to go 
away anytime soon.

Regards,

Hans




More information about the fedora-devel-list mailing list