[Rpm-maint] join wiki edit group; intro; cross development

Mark Hatle mark.hatle at windriver.com
Tue Dec 26 16:34:35 UTC 2006

I was involved in the creation of RPM at MontaVista, and am currently in
charge of RPM at Wind River..  So I have some insight into the current
embedded system uses of RPM.

While obvious to those who have done cross-development work, the things
that come to my mind first when talking about using RPM for embedded

*) Macro changes to assist/allow cross compiling

*) Package installs require --root=

*) If the user is not root, then we have to "fake" the chroot (for cross
development permissions, device nodes and other special files/items are
not necessary!)

*) Berkley DB _HATES_ being created on one arch and used on another.
(Mostly locking issues.. the endian issues were resolved a long time
ago.  Thus the addition of sqlite support into RPM as an alternative
database type.)

*) Transaction scripts, you can't just run scripts and expect them to
work in a --root= install, unless you use something like QEMU, you can't
actually execute the target apps on the host (in most cases).  (lua is
the answer to this IMHO)

*) You CAN NOT run /sbin/ldconfig when doing a cross install!  (AFAIK,
there is no way to run ldconfig in a cross environment.)

*) Helper scripts like find-debug-info need changes to work in a cross

(In both the MV and WR environments, they require RPM to contain no
internal absolute paths.  RPM needs to work relative from it's run-time


Ken MacLeod wrote:
> Hi all, I'm a long time RPM user, participated some on the rpm-devel
> mail list waay long time ago (I suggested BuildRequires, iirc).  I'm
> doing embedded cross development now and we're beginning to use RPM
> and associated build tools (like plague/mock) pretty heavily.  Several
> embedded Linux vendors are using RPM and most have modified versions
> that help prevent mis-installs on the host system, maintain multiple
> cross-target and cross-tool filesystems, and add rpmbuild macros for
> cross compiling.
> I'd be starting with a page on cross development RPM issues and a
> survey of current implementation.
> Thanks,
>  -- Ken
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> https://lists.rpm.org/mailman/listinfo/rpm-maint

More information about the Rpm-maint mailing list