Layer chunk with rpmostree-unpackaged-content and initramfs balloons update size

[antheas]

Describe the bug

Currently, rpm-ostree tags non-packaged files with rpmostree-unpackaged-content and initramfs with initramfs and gives them the maximum change frequency. This leads to them being placed at the same layer in the end, which is around 350MB in my case.

Since rpm-ostree does not allow skipping initramfs regeneration during building, this leads to a minimum update size of 350MB. For small updates (e.g., 3-4 layer changes of around 200mb), this constitutes around half of the update size

Reproduction steps

Build an image + container (in my case with tree, container-encapsulate) and immediately rebuild it with --cache-only.

The build options for those images included --previous-build-manifest, rpmdb-normalize: True with export SOURCE_DATE_EPOCH={{build_timestamp}}.

Expected behavior

The update size should be around 50mb instead of ~400mb.

Actual behavior

The only major layer change is that one with 350mb total. Another 10mb layer changed. Total update size 380mb.

System details

rpm-ostree:
Version: '2024.5'
Git: v2024.5-57-g5be2ecffa565a75d61100a5d65469cf8aabeaf80
Features:

• rust
• compose
• container
• fedora-integration

Inside the docker container quay.io/coreos-assembler/fcos-buildroot:testing-devel, patched to fix #4609

Additional information

I know diffed layers is a feature that is being worked on. However, even at its current state, the chunking algorithm is great!

It would be nice if initramfs could be generated in a deterministic manner and if not placed on its own layer.

Additionally, unpackaged files could be grouped a bit better and spread around other layers.

Those two combined could strip 200mb out of the update size before chunked layers arrive.