The packaging classes add support for generating packages from a build's output. The core generic functionality is in package.bbclass. The code specific to particular package types is contained in various sub-classes such as package_deb.bbclass, package_ipk.bbclass, and package_rpm.bbclass. Most users will want one or more of these classes.

You can control the list of resulting package formats by using the PACKAGE_CLASSES variable defined in the local.conf configuration file, which is located in the conf folder of the Source Directory. When defining the variable, you can specify one or more package types. Since images are generated from packages, a packaging class is needed to enable image generation. The first class listed in this variable is used for image generation.

The package class you choose can affect build-time performance and has space ramifications. In general, building a package with RPM takes about thirty percent more time as compared to using IPK to build the same or similar package. This comparison takes into account a complete build of the package with all dependencies previously built. The reason for this discrepancy is because the RPM package manager creates and processes more metadata than the IPK package manager. Consequently, you might consider setting PACKAGE_CLASSES to "package_ipk" if you are building smaller systems.

Keep in mind, however, that RPM starts to provide more abilities than IPK due to the fact that it processes more metadata. For example, this information includes individual file types, file checksum generation and evaluation on install, sparse file support, conflict detection and resolution for multilib systems, ACID style upgrade, and repackaging abilities for rollbacks.

Another consideration for packages built using the RPM package manager is space. For smaller systems, the extra space used for the Berkley Database and the amount of metadata can affect your ability to do on-device upgrades.

You can find additional information on the effects of the package class at these two Yocto Project mailing list links: