Build artifacts

Every time bsp completes a build, it will create at least 2 packages. We will discuss what they are in this article.

linux-rockchip 5.10.110-5 release will be used as an example.

Specifically, we will focus on the following 3 packages:

Debian package naming convention

Generall, Debian packages are named in the following format:

PACKAGE-NAME _ PACKAGE-VERSION _ PACKAGE-ARCHITCTURE .deb

The three components are seperated by the underscore.

Binary package

Binary package is the artifacts generated by the related source code.

They are large because they contain the real code.

In the above list linux-headers-5.10.110-5-rockchip is the real package.

For kernel related package, we additionally adds part of the package version to the package name, which is why you see 5.10.110-5 repeated in the package name above. The advantage of this is that now different versions of kernel are actually different packages (remember they are identified by the package name). This allows us to install different kernels at the same time, and the user can decided which one to boot at run time.

For firmware package, we only allow a single package to be installed (i.e. no version in the name). This is because firmware has to be installed in a fixed place, so it is not possible to switch between them.

In above list you also see 1932709cf is included in the package version. This is the base commit ID in case the related bsp profile is defined with a Git branch. This way we can determine which exact commit was used at the time of building.

Metapackages

One issue introduced by having a unique name for each kernel package is that now it is very hard to track which kernel supports what products, and there is no automatic upgrade since each new version is an entire new package.

To solve this problem, metapackages are built by bsp along with the binary package.

The list of metapackages is based on SUPPORTED_BOARDS defined in fork.conf. The purposes for them are:

1. They reference the latest binary package as their dependency.
2. Since they do not have a unique name per release, they can be updated, which will automatically pulls the new binary package as the dependency.
3. They also have a consistent name, so this makes tracking kernel with product a non-issue.

Beyond the supported products defined in SUPPORTED_BOARDS, we also define the profile name as a metapackage. This allows the user to install a specific profile of kernel/firmware instead of worrying about product updates it's source code dependencies.

Metapackages are usually very small since they only need to reference the binary package, and contains no code.

In above list you also see 3a557f6 is included in the package version. Since they are created entirely by bsp, this is the bsp commit used at the build time.