[lsb-discuss] Definitive use of /etc/* files for system-wide application data maintenance

[Denis Silakov]

Bruce Dubbs wrote:
> The only reason to have both
> 32-bit and 64-bit applications on the same system is to support old,
> unmaintained software that can't be rebuilt as 64-bit executables or
> libraries.  
>   

I would agree that moving to 'pure' 64bit systems is a nice thing.
However, though most programs can be successfully built in 64bit mode,
those few apps that currently support 32bit only can be rather important
for users.

I am far from asserting that all such 'problematic' software is really
old and unsupported. First, it's not so easy to rebuild some programs
for 64bit - the first example that comes to my mind is wine (surely,
there is great progress there, but wine64 is really experimental at the
moment). Yes, this is quite a specific program, but very useful in some
cases (at least for me:)).

Second, there are some rather popular proprietary programs that are
available only as 32bit binaries - e.g. skype, gizmo or adobe reader.
Such programs are not moving towards 64bit support as fast as open
source ones.

So I'd say that at the current state of art 'pure' 64bit system can be a
little less functional than its 32bit analogue. Finally, providing 32bit
libs in addition to 64bit once is really easy and relatively cheap, so
why not to do this?

On the other hand, it can make sense to provide them as some optional
part of the system - for example, take a look at 64bit ArchLinux. By
default, it only provides 64 bit libraries (located in /lib and
/usr/lib, there are no *lib64 folders at all). You can install lib32*
packages for particular libraries (all such libs will go to
subdirectories inside /opt/lib32/), or even setup a 32bit chroot (maybe
not very convenient, but more reliable).

But ArchLinux is an exception to the rule, the common practice is still
to have */lib for 32bit libs and */lib64 for 64bit ones. So probably
it's too early to deprecate lib64 in the FHS.

-- 
Regards,
Denis.