Bdale Garbee wrote: > That's great news, thanks for the report. The ia32-libs package is a bit of > a hack, and I'm never quite sure when to update it. It's probably about time > for a respin, though, before we're totally frozen for sarge release.
I have stopped using the ia32-libs package entirely. Instead I use a full x86 chroot in /emul and update it using APT. This works much better for me and is much easier to keep updated correctly than other methods I have tried. Here is the recipe I have been using. The Debian chroot process is described in the reference manual. http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot I have never been able to get the debootstrap process to work cross-platform. Therefore I first build the chroot natively on a ia32 platform following the documented process above using debootstrap. Then second I copy the chroot onto the ia64 machine. sudo rsync -a /woody/ [EMAIL PROTECTED]:/emul/ia32-linux/ At this time the instructions can be resumed immediately after the debootstrap. The ia32 chroot area can be updated with a full stable release or updated to sid as is your preference. I personally do not mount /proc as suggested in the chroot setup reference. Without /proc I tend to avoid collisions when some daemon packages try to kill the running daemons and start new ones in the chroot. sudo chroot /emul/ia32-linux apt-get update apt-get install packages apt-get upgrade Great! But running in the chroot is not as friendly when you are trying to enable it for compatibility mode. Here are the final steps. Edit /etc/ld.so.conf and change the library paths to be the following. /usr/X11R6/lib /emul/ia32-linux/usr/lib /emul/ia32-linux/lib /emul/ia32-linux/usr/X11R6/lib Then run 'ldconfig' (or 'ldconfig -v') to update the runtime link cache. ldconfig -v What happens next depends upon whether you have ia32-libs installed or not. If you do then you have a symlink from /lib/ld-linux.so.2 to /emul/ia32-linux/lib/ld-linux.so.2 which should work fine. But since my goal was to replace that methodology with this alternative I removed or have not installed ia32-libs on my machines. In which case we need to make our own symlink to our own ia32 chroot area. sudo ln -fns /emul/ia32-linux/lib/ld-linux.so.2 /lib/ld-linux.so.2 At this time it is possible to run all of the ia32 legacy applications which may not have been ported to native ia64. It is possible to set PATH to fall into the ia32 directory. PATH=$PATH:/emul/ia32-linux/usr/bin Now when updates are needed to be installed one can run the normal commands to update the chroot area. This is the key benefit of this alternative technique to the ia32-libs package. The maintenance of the ia32 binaries are done using normal techniques familiar to the administrator. sudo chroot /emul/ia32-linux apt-get update apt-get -u upgrade Will all applications work this way out of the box? No. Any application in the /emul/ia32-linux root which needs files rooted in / will not find them. For example, if openoffice is installed in the /emul/ia32-linux root instead of the real systems root then it will look for /etc/openoffice and not find it since it is really installed in /emul/ia32-linux/etc/openoffice in the install area. Similar for /usr/lib/openoffice. In order to make those applications work you will need to create a symlink to the install location. File /emul/ia32-linux/usr/bin/openoffice: #!/bin/sh [ -r /etc/openoffice/openoffice.conf ] && . /etc/openoffice/openoffice.conf Effectively in this environment it is a mix of executables. The shell script itself runs natively and therefore does not see the files in the emulation root. But the binaries run in compatibility mode and do the files in the emulation root. The symlink is only needed for shell wrappers such as the wrapper from OOo. sudo ln -fns /emul/ia32-linux/etc/openoffice /etc/openoffice sudo ln -fns /emul/ia32-linux/usr/lib/openoffice /usr/lib/openoffice Of course one could modify /bin/sh to be x86 emulated and then emulated which would trigger this behavior as needed. But there would be a performance and capacity penalty for all /bin/sh scripts in that case which would be undesirable so I can't recommend that. I think the only answer for these types of problems is the symlink back into the ia32 root for specific targets which require it. It works sufficiently. And besides eventually everyone will have 64-bit clean code so this won't be needed because we will be running native code everywhere, right? :-) Am I completely satisfied with this technique? Pretty much. But not completely. I don't like the symlinks that I have created which are not managed by the package manager. They were needed to make the packages find /etc/ conffiles. But when it comes time to install native applications those will get in the way and need to be cleaned up first. I should instead create an adaptor symlink deb package which conflicts with the real native package so that when the native package becomes available and is installed the adaptor symlinks will be automatically removed. But I am lazy and this worked sufficiently. I hope this has been of benefit. I am interested in any feedback or comments which this list discussion might generate. This was discussed previously on this list. But it has been a while and some of the details have changed so it seemed reasonable to repost the summary. Bob
