Ng Oon-Ee wrote:
I resent your characterization of my post_install function as abuse. No .install files were harmed in the making of my arch32-light package. :)
Ah, I think I must have been taken a bit too literally here. I was actually quoting your own description of how arch32-light does its work =). I myself think its a good way to set up a chroot, and should probably be considered the 'canonical' way currently (if I'm not wrong, you basically automate most of the steps in the 32-bit chroot wiki).
I was actually talking about a package/script to handle chroot maintenance generally, where your pacman32 is specific to the arch32-light package. Of course, having bauerbill handle that for me would be lovely =)
Don't worry, I was only joking about the resentment, whence the smiley. And yes, the package automates the steps in the Wiki to set up the minimal 32-bit chroot. There is also an "arch32" package in the AUR that follows the steps to create a full chroot. What I meant with my previous footnote is that it is easy to create aliases and scripts to handle chroots. All you really need are the "--root", "--cachedir" and "--arch" options, and occasionally the "--config" option. E.g.: ~~~~~{Bash} function in_arch_root { root_dir="$1" shift "$@" --root "$root_dir" --cachedir "$root_dir/var/cache/pacman/pkg" } in_arch_root "/opt/arch32" pacman --arch i686 -Syu ~~~~~ If you have multiple chroots then you should probably use a common cachedir (e.g. /var/cache/pacman/pkg), although it would only be accessible from outside of the chroots, which may or may not be a problem depending on how you manage them. Links might work too. You could also create update functions that loop over a list or array of chroots and update each one accordingly. It all comes down to just a few lines in .bashrc or a bash script, so there isn't any real reason to try to package it. Btw, bauerbill can handle chroots using the same options, as pacman's options are a subset of powerpill's and bauerbill's options .