You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came up in ostreedev/ostree#1922. Essentially, the idea is to make garbage collection smarter by always keeping at least the last two versions of deployments. This prevents repeated layered commits (from e.g. rpm-ostree install commands) from flushing out the previous version's deployment.
The rationale is that for e.g. Silverblue/FCOS systems, the version string is associated with a specific snapshot of Fedora content. So in general, they're more meaningful deltas in terms of fallback than local recomposes from install operations.
The text was updated successfully, but these errors were encountered:
I filed this here, but I think most of the work for this would take place in libostree. E.g. have a new OstreeSysrootSimpleWriteDeploymentFlags flag like OSTREE_SYSROOT_SIMPLE_WRITE_DEPLOYMENT_FLAGS_RETAIN_PREVIOUS_VERSION? Though offhand, looks like at least this TODO would have to be addressed so that the staging path (which is the default now) can pass that flag along.
This came up in ostreedev/ostree#1922. Essentially, the idea is to make garbage collection smarter by always keeping at least the last two versions of deployments. This prevents repeated layered commits (from e.g.
rpm-ostree install
commands) from flushing out the previous version's deployment.The rationale is that for e.g. Silverblue/FCOS systems, the version string is associated with a specific snapshot of Fedora content. So in general, they're more meaningful deltas in terms of fallback than local recomposes from
install
operations.The text was updated successfully, but these errors were encountered: