[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Why not /usr/bin64?





2006/1/17, Mike A. Harris <mharris mharris ca>:
Rudolf Kastl wrote:
> its needed once i got it building for x86_64 completly and i am in
> contact with the maintainer for wine in extras. Just wanted to actually
> state the obvious since there are cases where 32 bit and 64 bit binaries
> make sense to be parallel installed.

On the existing 32bit architectures, /usr/bin is 32bit binaries, and
on the existing 64bit architectures, /usr/bin is 64bit binaries.

One of the goals of multilib, is that the 32bit binaries produced on
the 32bit version of the OS (ie: ppc binaries, x86 binaries) are
intended to be installed directly on the 64bit OS for the corresponding
CPU (ppc64, AMD64).  Since the 32bit OS's predate the 64bit ones,
the 32bit OS's used /usr/bin for their 32bit binaries first, and
there is a plethora of them out there.  Rebuilding them all to
install into /usr/bin32 is just not a feasible solution for the
long term, and considering the number of packages out there that
are affected by the described problem, it just isn't a warranted
solution to create a bin32 directory.

Likewise, /usr/bin is the location that binaries have been installed
on the 64bit OS variants all along.  Changing that to /usr/bin64 would
create a lot of confusion and a very large workload not just for OS
packagers, but for the entire community out there.  I believe it
would also break the defined ABI of those 64bit OSs.

There are really very few applications which are affected by this
type of problem it seems.  I would think that a case by case solution
to the problems is a superior path to go considering the existing
momentum, and weighing the various advantages and disadvantages to
any proposed solution.

This can be handled either by using chroot jails with full 32bit
OS installs for special cases like wine, etc. or by creating custom
packaging for both the 32bit and 64bit variants of a package which
allow them to coexist within one OS install.  I have written a
small shellscript named "archexec" which is perfect for this
purpose.  It is included in the xorg-x11 packaging in Fedora Core 4
and RHEL4, although it is currently absent from Fedora Core 5, as
the problems I designed it to solve, are not present in X11R7, so
it just got left out - however it is a general purpose tool which
I believe would be useful to have in core-utils or somesuch.

By using archexec, and slightly customized packages, it is possible
to install both 32bit and 64bit binaries on a single system, without
creating any extra /usr/bin64 mess, and the appropriate binary will
be executed depending on the current architecture in use.  For the
case in which one might want to run the 32bit binary while in a 64bit
OS, doing so using setarch should be possible.

For more complicated cases (if there are any), surely a chroot is
the best way to go.  Another option, is to use Xen, and run both
32bit and 64bit OS's simultaneously.  That's going to get even easier
later this year when AMD releases their Pacifica technology.

YMMV

--
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                      Proud Canadian.
 
 I agree completly here. it would create a huge mess for a few special cases. parallel packaging of wine64 and wine (32bit version) is not a real problem its possible and for this case no chroot is really needed unless there are missing 32 bit compat libs in x86_64.
 
regards,
rudolf kastl
 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]