If the filesystem is not of the same architecture, then one cannot use the chroot method. However, one could cross-compile with an alternate makepkg.conf and then install to the guest system with "pacman -r guest_path". On 29 July 2011 03:33, Allan McRae <allan@archlinux.org> wrote:
On 28/07/11 01:49, Dave Reisner wrote:
On Wed, Jul 27, 2011 at 10:31:30AM -0500, Matthew Farkas-Dyck wrote:
Patch to make makepkg keep PACMAN_OPTS environment variable, thus allowing operation to be better controlled, e.g. by an AUR- or other helper script to build packages on and install packages to a mounted guest filesystem.
--- pacman-3.5.3_/scripts/makepkg.sh.in 2011-06-07 10:49:28.000000000 -0500 +++ pacman-3.5.3/scripts/makepkg.sh.in 2011-07-27 09:33:11.413361098 -0500 @@ -80,8 +80,6 @@ # when dealing with svn/cvs/etc PKGBUILDs. FORCE_VER=""
-PACMAN_OPTS= - ### SUBROUTINES ###
plain() {
Cheers, Matthew Farkas-Dyck
A few things:
1) We accept properly formatted patches against our git repository:
http://www.archlinux.org/pacman/submitting-patches.html
The source of makepkg has changed significantly as since v3.5.3, there's been 505 commits with 10% of those going to makepkg.
2) This would be an undocumented feature that should be called out in the man page.
3) Not sure I agree with this change in execution as randomly pulling in environment variables can and will cause trouble. I'd rather see this implemented as an additional flag to makepkg.
Hmm.... I thought we maybe already had this feature...
PACMAN="pacman --asdep" makepkg -i ==> WARNING: A package has already been built, installing existing package... ==> Installing package python-six with pacman --asdep -U... sudo: pacman --asdep: command not found
So that does not work... but it would be probably be a very minimal change to make it do so.
But I am still not entirely sure what is trying to be achieved here. If you want to build and install packages on a mounted filesystem, you need to chroot to that filesystem. Otherwise, you a building locally. So using --root as a flag is probably not enough anyway...
Allan
-- Matthew Farkas-Dyck