Cross-architecture package installs

Tim Kientzle kientzle at
Wed Feb 6 06:34:29 UTC 2013

I'm working on tools to build ARM system images.
Usually, these tools run on x86, which creates a problem
for packages.

I would like to install packages onto the image as it's built.
So I've been experimenting with variations of
   pkg -c <DESTDIR> add <package files>

I'm running into a few problems but I think they can all be
solved.  Only the first is critical; the rest are relatively
minor annoyances.

1) Pre-install/post-install scripts.

    These obviously don't work since the DESTDIR
    is for a different architecture.

    At least for post-install, it should be possible to
    record which packages still need their post-install
    scripts run and arrange to run them after first
    boot.  I'm picturing an rc.d script that invokes pkg
    with appropriate options to find all packages
    that still need their post-install run and runs them.

    This won't work for pre-install, but those are rarer
    and we can hopefully work around them on a
    case-by-case basis.

2) The chroot happens before opening the package files.

    It's possible to work around this by copying all of the
    package files into DESTDIR first, but that's both
    time-consuming and rather awkward.  (And quite
    tricky if you're installing directly onto a mounted
    image that has very little free space.)

    It should be feasible to open the package files first
    and then chroot.  Then the actual installation still
    happens entirely inside DESTDIR.

3) Bogus "failed to install" messages.

    As far as I can tell, if "bar" depends on "foo", then
    "pkg add bar foo" will do this:

    Installing bar …
        Installing foo …
    Installing foo … foo already installed.

    Failed to install the following package: foo.

    This is surprising since foo did in fact get installed.

    In my case, I want to say "pkg add *" and just have
    it DTRT.  It mostly does get the ordering right (I'm impressed!)
    but the error message is a bit odd.

More information about the freebsd-current mailing list