Why not /usr/bin64?

[Rudolf Kastl]

2006/1/17, Mike A. Harris <mharris at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060117/b16398c8/attachment.htm>