[MPlayer-dev-eng] [PATCH] Paths for x86_64

[Christof Buergi]

Am Donnerstag, 30. Dezember 2004 21.43 schrieb D Richard Felker III:
> > Maybe it is, maybe it isn't. But it still is the best accepted
> > standard available. In fact, several distributions switched to it,
> > because their userbase demanded it. Thus, FHS has some kind of
> > legitimacy.
> only among users of commercial/proprietary dists.

No. Gentoo, for instance, is adhering to FHS quite closely.

> that your lug is full of idiots. at least that's the consensus i
> reached... :)

Well, thanks. I take that as a compliment. ;-)

> > a) a pure 64bit operating system with encapsulated 32bit
> > applications is cleaner then a hybrid system, but impractical.
> this is nonsense. why would you need any 32bit apps whatsoever?? just
> recompile.

First off, there are applications with no open source alternative. Some 
of the Windows-Codecs that MPlayer uses, for instance. Another problem 
are applications that have not been written with portability in mind. 
Those may break when recompiled for 64bit. Trust me: There are such 
applications. Otherwise, we wouldn't have had that discussion.

> > b) usability is more important then ideology.
> this is not usability vs ideology. it's short-term hacks versus
> long-term usability. adding hacks to every program to make it install
> libs in lib64 if arch==x86_64 is totally impractical and not usable.

Well, the people on our list still found it more user friendly to change 
a few makefiles (which is usually done by the package maintainers), 
then putting every single one of those special applications that they 
only got as a 32bit binary in a chroot jail. And I doubt that those 
applications will go away in a hurry.

>> c) a pure 64bit system for x86_64 is not necessarily the best
>> solution, as the Opteron/Athlon64 is not a pure 64bit CPU, and the
>> Xeon with x86_64 support is no 64bit CPU at all.
> huh? this is an idiotic windoze-like way of thinking.

Let me put this another way: Many do look at the Opteron not as a 64bit 
CPU, but as a 32bit CPU with a 64bit extension. In fact, many 
applications don't run faster in 64bit mode and don't use more than 4GB 
of RAM, so why bother adapting them to 64bit? The Opteron's ability to 
run 64bit code and 32bit code natively at the same time is the one 
reason that makes it so much better accepted than the Itanium. Why 
should we throw that away? Backwards compatibility lately got a bad 
name, but it still is considered to be an advantage, not a 
disadvantage.

> i don't care. supporting lib64 is the business of the distributor if
> they want that crap, NOT the responsibility of every single software
> author.

Normally I would agree, but MPlayer is special. It's users are (heavily) 
encouraged to get the software from here, not from the distributors. 
Thus, listening to what the user wants might not be such a bad idea at 
times. Today, every single x86_64 distribution I know of except Debian 
is using the lib64 approach, and Debian isn't representing the majority 
of the community. To shun lib64 altogether or to have an option "use 
lib64 paths (for broken systems)" is actually like saying "every distro 
but Debian is broken". I'm afraid that would be very ill received.