I've been attempting to make a PoC of this. So far, it's not been successful due to limitations in the existing containers-image-proxy tooling (not trivial to download SBOM artifacts), but it's given me chance to think through things a bit.

I am hesitant to suggest integrating bootc with dnf directly, since I would hope Bootc would work just as well with other distros over time, without expecting a large amount of work in the other package managers.

There's a few ways I have been playing with. All work in roughly the same way.

SBOM Attestation Comparison

The first is comparing SBOM OCI artifacts between the booted and staged (or rollback) deployments. The main benefit of this option is since "it's okay not to use RPMs" - Dan Walsh, 2024, these SBOM tools already know how to extract versions from binaries and other files on the system too.

During the updates or switches, Bootc calls out to the registry providing the image and pulls the OCI SBOM artifact and ingests only the package names and versions (since that's all these diffs cares about). From there, it's trivial to convert that to a map (package_name -> version) and allows us to easily say which have been added, removed or changed.

To speed up this diffing, we can cache the booted SBOMs as a readonly file on disk (/usr/lib/bootc/sbom.json), meaning we only need to pull a single artifact.

Generate package lists during build / stored in image

As a part of the build, either bootc container lint or the proposed bootc container commit, call a binary (something like bootc-package-list... Naming is hard) which each distro would provide. This binary knows how to list all packages in the system and outputs them to a well-known file in the image.

# /usr/lib/bootc/packages.json
{
  "packages": [
    {
      "name": "kernel",
      "versionInfo": "6.14.2-300"
    }
  ]
}

Fun fact: this schema is the same as SPDX produces, so a user can choose to inject an SBOM onto the image here, too.

Bootc can then read the file from both the booted and image requested for comparison, and do the same as SBOMs - create a "added", "removed" and "changed" list which is displayed to the user.

Generate package lists during switch/update / runtime

Similar to the previous, expect a bootc-package-list binary on the system which has knowledge of how to extract the packages on the system. This binary can write the package list to stdout or a temp file created by Bootc with the above schema.

Bootc calls the bootc-package-list binary on both the current sysroot and requested image sysroot, and bootc compares the two lists.

The nice thing about the first two options is someone can do a sort of "dry-run" switch very quickly, without pulling down a full image or staging them. Bootc can just pull down the necessary files from the registry(*1) and say "if you go through with this action, 10 packages will be changed".

(*1) assuming zstd:chunked or composefs allows you to pull a specific file from a registry... Not sure

status: add diff for cached update #932

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions