Update the Highlights and Understanding components sections to reflect
that pacman (ALPM) is now a supported component repo alongside RPM.
Assisted-by: Pi (Claude Opus 4.6)
For bootable containers let's add a note about minimum versions
of bootc required to use chunkah chunked images. The versions are
v1.1.3, which contains [1] for images <= 128 layers, and v1.9.0,
which contains [2], for images with > 128 layers.
[1] c49ccec505
[2] 207b7f0abf
In the `podman run chunkah | podman load` flow for splitting an existing
image, it's annoying that the resulting image is unnamed. Add support
for a `-t`/`--tag` switch which sets the right annotation on the
manifest descriptor in the OCI archive that e.g. `podman` and `docker`
pay attention to.
While we're here, update the Docker docs; the containerd backend does
support OCI archives natively and that's the default backend nowadays.
So that simplifies things nicely and makes it almost identical to the
podman instructions.
Assisted-by: OpenCode (Claude Opus 4.6)
This is the second part of #98. If the user didn't provide any interval
via the new xattr API, assume weekly.
Previously, we were using the fallback of (minimum stability)/2, which
(1) is way too sensitive to churny outliers in the package set, and (2)
doesn't really have a basis in what users are expressing.
I'm converting users' intent of bothering to add an xattr here
as them saying that it has _some_ amount of stability, which I'm
semi-arbitrarily ballparking as 'weekly'.
While we're here, tweak the README section on xattrs a bit more to
reflect reality.
Allow users to specify the stability of xattr components via
`user.update-interval`. The value can be either a positive integer
representing the average update interval in days (e.g. '30') or a
named label (daily, weekly, biweekly, monthly, quarterly, yearly). That
makes it easier to understand than having them plug in the probability
directly.
This plugs a notable gap we've had so far in the xattr repo, which
without this information was useful mostly when there was no to little
packing pressure. As soon as aggressive packing is required, treating a
high stability component as low can lead to suboptimal outcomes.
Closes: #98
Assisted-by: OpenCode (Claude Opus 4.6)
There's real world usage of chunkah at this point in various places that
have proved it out and I feel pretty good about the current UX. It's
unlikely we'll break those users.
Let's drop the alert box to help it go farther!
Past versions have been migrated from quay.io/jlebon/chunkah to
quay.io/coreos/chunkah. Update all references to point to the new
location, including the CI workflow, docs, and tooling.
Assisted-by: OpenCode (Claude Opus 4.6)
There's a bunch of things that were under-documented or not documented
at all. There's also a mention of a cap on `--max-layers` which was
never implemented.
The buildah layer annotation bug[[1]] only manifests in the buildah flow
when adding additional instructions after the final `FROM oci-archive:`.
Move the related note to that section instead and clarify this.
[1]: https://github.com/containers/buildah/issues/6652
I was hesitant to document this because there's various subtle gotchas,
but people are doing it anyway, so we might as well provide guidance and
document those gotchas.
This also documents a `CHUNKAH_CONFIG_STR` build arg one could add in
the buildah flow to persist base image metadata without having to repeat
it.
Assisted-by: Claude Opus 4.6
One thing sorely missing right now is any feedback of what chunkah is
doing.
This remedies the situation quite a bit by hooking up the tracing crate
and adding logging throughout the codebase. I might've went overboard
with the trace level, though it's really nice to be able to follow
exactly the data flow for any given path, from scanning, claiming,
packing, merging, and serializing to tar.
Change all our e2e tests to use the debug level.
Assisted-by: Claude Opus 4.5
Closes: https://github.com/coreos/chunkah/issues/17
Let's just have it always match the latest release.
Generalize the `lockcheck` CI check to become `versioncheck`, which also
covers the README.md. The grep lines are a bit yucky but meh.
Assisted-by: Claude Opus 4.5
