<div>2006/1/17, Mike A. Harris <<a href="mailto:mharris@mharris.ca">mharris@mharris.ca</a>>: <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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 * <a href="http://mharris.ca">http://mharris.ca</a> Proud Canadian. </blockquote> <div> </div> <div> 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. </div> <div> </div> <div>regards,</div> <div>rudolf kastl </div></div>