[poky] RPM vs IPK

[Stewart, David C]

> From: poky-bounces at yoctoproject.org [mailto:poky-
> bounces at yoctoproject.org] On Behalf Of Gary Thomas
> Sent: Thursday, May 19, 2011 7:26 AM
> 
> 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.

I agree - hey Gary, can you please file a Bugzilla to add this to the Reference Manual?  Thanks...