| Index | US094 |
| Title | Kernel Accessories Seed and Metapackage |
| Status | Pending Review |
| Author | Robie Basak |
| Type | Standard |
| Created | 2023-02-02 |
Abstract
We want the default set of packages installed on an Ubuntu system to vary depending on whether the substrate contains a kernel or not. We introduce a new kernel-accessories seed and metapackage to abstract a list of default packages for installers and image generators to use.
Rationale
In FO147, we want to make bpftrace and bpfcc-tools available by default on most Ubuntu systems. Normally, we would just add these to a suitable seed, such as standard or server. But lxd images contain no kernel, are generated from these seeds, and adding these packages would result in unnecessary image size bloat. We assume that BPF-related tooling would only make sense on a host, unless in a specially privileged container that has been prepared specifically for such use. This means it would be inappropriate for us to add BPF-related tooling to lxd images by default.
It seems inappropriate to special case these packages in every installer and image generator, so instead we will use a metapackage driven by a new seed.
Specification
From Noble onwards:
-
We shall introduce a new seed called kernel-accessories, and a new metapackage derived from it.
-
An appropriate kernel metapackage from src:linux-meta shall Recommend the kernel-accessories metapackage.
-
The seed shall be defined as “packages that should be installed by default when a kernel is installed by default”. The initial set of packages in this seed shall be defined by FO147.
Packages added to this seed (whether now or in the future) should not ship any services that are enabled by default.
Further Information
Implementation mechanism
Implementation requires addition of the Recommends to src:linux-meta only, as specified above. This will cause the metapackage to be pulled in automatically both on fresh installations and on release upgrades.
Deployments which do not include Recommends by default, such as cloud-minimal, will not pull in this metapackage. This is the desired behaviour.
Rationale for metapackage
Using a metapackage that connects to the rest of the dependency tree from the existing kernel metapackage means that users’ systems will automatically maintain the set of packages we wish to pull in, over this and future release upgrades, without any further mechanism that needs to be implemented.
In more detail: as we change the set of “kernel accessory” packages over multiple distribution releases in the future, we would like users to stay “in sync” with this set unless they opt out of this management. This allows us to prevent skew between a fresh Ubuntu installation in a given release and an Ubuntu installation that has been release-upgraded up to it. By using a Recommends from the kernel metapackage, we further gain consistency even within the release that first introduces this metapackage without needing a quirk in ubuntu-release-upgrader to handle the upgrade path.
Alternate deployment mechanism
Instead of using Recommends from the existing kernel metapackage, we might have arranged for installers and image generators to separately pull in the metapackage at the time of installing a kernel. This would also allow for differentiation based on installer type, such as if we had wanted to make this package server-specific. However, this would have needed separate implementation in a variety of places, release upgrade quirks to “catch up” from older releases would have been required.
Further, differentiation between server and desktop images has been indicated by product management as undesirable. It is preferable for default behaviour to match unless there is a good reason to avoid this, so that users familiar with one environment can be automatically familiar with the other. Image size difference wasn’t considered to be large enough to warrant differentiation.
Other candidate packages for this new seed
It might make sense in the future to move more packages into this new seed. However, such potential changes are deferred for now. Some packages that are currently seeded in the server, including in container images, have been proposed as candidates for these future changes, if they make sense to install by default if and only if a kernel is installed by default:
-
lvm2
-
multipath-tools, though the systemd unit at least prevents that for running by default in containers so the benefit would be strictly about size
Image and Deployment Size Implications
Actually using this new metapackage has an implication of increased image size and installation size. This is really a matter for the separate spec that will define what packages will be added and consider those trade-offs, and are out of scope of this spec. However, in the decisions taken in this spec, we narrow our opportunity to differentiate based on image type (eg. Desktop vs. Server) and it is reasonable to consider whether this is appropriate. Product management has indicated that this is acceptable.