Cross-architecture package installs

Baptiste Daroussin bapt at
Wed Feb 6 06:55:20 UTC 2013

On Tue, Feb 05, 2013 at 10:34:18PM -0800, Tim Kientzle wrote:
> I'm working on tools to build ARM system images.
> Usually, these tools run on x86, which creates a problem
> for packages.

First Yes cross-installation of packages is something we highly want in pkgng
and is plan since the beginning, that is one of the reason pkg -c is readig the
ABI from the DESTDIR, to make sure we only install things that are abi

> 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.

This is imho the main problem, and one of the long term goal of pkgng is to remove
as much as possible any pre-instal/post-install scripts. The second problem you
will get into is the API that call system()/exec()/etc for example all the call
the pw_mkdb from libutil :(

We are open for all suggestions here

> 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.

In fact pkg add is only mean to be used in special case if in that particular
case you would have used pkg -c DESTDIR install <packagename> using a repository
you would have created on your host using pkg repo to create the metadata thing
necessary. problem your packagesite should served via a http/ftp not file except
if the files are also locate inside the chroot.

> 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 …
>         done
>     done
>     Installing foo … foo already installed.

Yeah as said above pkg add as to be forgotten as much as possible, it has been
created mostly for the ports tree and the ports build script so that they don't
need too much changes other that s/pkg_add/pkg add/g
>     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.

Just do "pkg install -x ." or "pkg install -g *" ordering would be ok without
odd message.

pkg add does not ordering, I'm surprised you got it right :)


PS: I CCed freebsd-pkg@, which is a new mailing list dedicated to this kind of
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <>

More information about the freebsd-current mailing list