Re: RPM vs IPK

[Mark Hatle <mark.hatle@windriver.com>]

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.

--Mark