[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
development:
*) 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
environment.
(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
location.)
--Mark
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