On 7/28/2012 4:40 PM, Linda Walsh wrote:
Linda Walsh wrote:
Nelson Marques wrote:
Ever heard of FHS? It's stands for Filesystem Hierarchy Standard.
Enjoy the reading :)
It is based on really screwed up reasoning. Why was it accepted?
Regardless, Suse doesn't follow it now, so why not move ahead with a more soundly reasoned solution.
Seems a smart solution would be to use a separate file-system namespace with everything but the bin & lib directories being the same between 32&64 bit.
Would provid transparency. Their rational .. that lib(X) is architecture dependent, also applies to /bin, yet they don't apply the same reasoning.
... more specifically under specific options, they also say: lib<qual> Alternate format essential shared libraries (optional)
"Lib<qual>" is for an alternate format. Alternate to what? I would assert alternate format doesn't mean native format. And that on a X64 machine running an X64 kernel where x32 compatibility is *optional*, that it is 32-bit dirs that are optional. So the document is internally inconsistent besides being.
========= I think having a smart loader that virtualizes the arch-dependent dirs.
To make it arch, blind, create a /usr64/{bin,lib}, then on any given machine, /usr/{bin,lib} can be mounts/links to the native binaries (/usr64 or /usr32...)...
Rational -- their rational was based on 8 year old data when x86-32 packages out numbered x86-64 packages. Clearly that doesn't apply on a modern x86-64 bit system -- where it's better than 3:1 64-bit (linux certainly has taken the lead on this). Existing 32 bit binaries would almost never work on a 64 bit system -- you would need to have the same libraries installed..
Does suse support taking 32bit binaries from 2004 and installing them on a 2012-suse12.1 system?
If not, the justification for this is negated.
What they don't mention is that existing programs are rebuilt, often from sources, and will build with the defaults for that platform. That being the case, it would require modification of those programs to work if their lib path wasn't "/usr/lib".
Supporting non-recompiled binaries from 8 or more years prior, I don't think has ever been supported. What were they thinking?
It is supported because commercial binaries cost a lot, are not practically replaceable, and are not recompilable. I routinely install such old 32bit-only binaries on new 64bit systems, from several different vendors, and all I need for them to work is matching 32bit libraries. If I couldn't do that, I couldn't use suse. There was a one time unique event (so far) that was outside suse's control where a kernel/libc interface change meant even statically linked bins couldn't go past a certain version. It wasn't just libc5 vs libc6. That was years ago by now. So perfect 100% backwards compatibility forever isn't possible, but that doesn't mean it isn't important. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org