[poky] RPM vs IPK

[Gary Thomas]

On 05/19/2011 08:17 AM, Mark Hatle wrote:
> On 5/19/11 9:05 AM, Gary Thomas wrote:
>> Building Poky for various targets, I see some striking differences
>> based on the packaging.  I'm building for the beagleboard (RPM)
>> and my own OMAP/3530 (IPK), so everything is the same for these
>> packages (same compiler, architecture, etc), only the package
>> method differs.  This was built on an otherwise idle box
>> 4-way (Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz), with
>>     BB_NUMBER_THREADS ?= "4"
>>     PARALLEL_MAKE ?= "-j 4"
>>
>> Each of these tests are a complete build of the package, with
>> all dependencies already built.  For example, I use this sequence:
>>     % bitbake perl
>>     % bitbake perl -c clean
>>     % rm sstate-cache/sstate-perl-arm*
>>     % time bitbake perl
>>
>> perl -      RPM                         IPK
>>          real    12m15.520s          real    9m43.228s
>>          user    5m42.988s           user    4m40.692s
>>          sys     3m56.636s           sys     2m19.860s
>>
>> eglibc     RPM                          IPK
>>          real    32m19.984s          real    23m52.124s
>>          user    15m32.732s          user    20m48.214s
>>          sys     17m28.087s          sys     9m3.936s
>>
>> Bottom line - it seems to take 20-30% longer to package via RPM.
>>
>> I know there are reasons and tradeoffs for different packaging
>> methods, but 30% extra?
>>
>
> This matches my expectations for the most part.  RPM creates and processes a lot
> more metadata then IPK.  IPK is well optimized for small systems, and certainly
> I would advise someone generating a small system to use IPK.
>
> For medium and (especially) large systems, RPM starts to give more abilities
> that IPK due to the additional meta data.  This includes individual file type
> information, file checksum generation and evaluation on install, sparse file
> support, conflict detection and resolution [for multilib systems], ACID style
> upgrade, repackaging abilities for rollback, etc..  (Some of the items for RPM
> are not yet enabled in oe-core, but could be by individual developers.)
>
> (I also wouldn't be surprised if we've got integration optimizations in the RPM
> backend in oe-core that could help with those numbers.  The numbers seem to be
> much worse on packages with large numbers of files, vs the typical package with
> only a few to a hundred or so files.)
>
> Downside of RPM for small systems is the Berkley DB and the amount of meta data.
>   If you will be doing on-device upgrades the space required to handle the
> berkley DB and related items is quite large..  Also many of the advanced
> features available in RPM simple are not needed in small systems.

Fair enough.  Perhaps the packaging type should be chosen based on
the target, e.g. the BeagleBoard probably would be best served by IPK.

Certainly, these data/tradeoffs should be made clear somewhere in the documentation.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------