Re: Openoffice.org
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/ root@ia64box:/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
Reply to: