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.
If you take the optional step to set up a repository (package feed) on the development host that can be used by Smart, you can install packages from the feed while you are running the image on the target (i.e. runtime installation of packages). For more information, see the "Using Runtime Package Management" section in the Yocto Project Development Manual.
The package class you choose can affect build-time performance and has space
ramifications.
In general, building a package with IPK takes about thirty percent less
time as compared to using RPM 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.
Before making your decision on package manager, however, you should consider some further things about using RPM:
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.
For smaller systems, the extra space used for the Berkley Database and the amount of metadata when using RPM can affect your ability to perform on-device upgrades.
You can find additional information on the effects of the package class at these two Yocto Project mailing list links: