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

[Mark Hatle]

I just wanted to add a clarification to my Berkley DB statement below (I
have already changed the wiki page to match.)

* A Berkley DB database HATES being created on one arch and used on
another. The contents of the database are intact and read-able
cross-endian. The problem is specific to locking. Different
architectures do locking in different ways which may cause problems.
(Clarified from original email.) It may be possible to build Berkley DB
on different architectures with the same locking formats, however there
may be endian specific items in the locking. (Also different
architectures may not support the same type of locking. Read the BDB
documentation when configuring the locking mechanisms.)

    * Note: sqlite was added to attempt to work around this issue. At a
tradeoff of slower performance, and no concurrent transactions. Sqlite
automatically addresses the locking issues in my experience.

--Mark

Mark Hatle wrote:
> 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
> 
>