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
{{ message }}
This repository has been archived by the owner on Feb 24, 2020. It is now read-only.
A Linux distribution packages rkt 0.12.0 and names it rkt-0.12.0-1.
Users try it and report a bug to the distro.
The distro adds their own patch in the package, and names the new version rkt-0.12.0-2.
Users update and try it.
The CAS will contain something like:
# rkt image list
ID NAME
sha512-6ae514fd1bfc coreos.com/rkt/stage1-host:0.12
But the CAS does not see distro versioning, so it will be coreos.com/rkt/stage1-host:0.12 for both 0.12.0-1 and 0.12.0-2. So the new stage1 with the distro patch will not be executed after the dist-upgrade because the old version will still be in the CAS. Users will have to manually run rkt image rm sha512-6ae514fd1bfc.
The text was updated successfully, but these errors were encountered:
@krnowak What should distros do to avoid this problem? Just use --with-stage1-default-version=0.12.0-2 to include the -2? It should be documented in packaging.md.
@alban: Hmph, currently, the only way to add the -2 suffix would be to patch the configure.ac. Replacing --with-stage1-default-flavor=host with --with-default-stage1-name=coreos.com/rkt/stage1-host --with-stage1-default-stage1-version=0.12.0-2 also will not help, because the build stage1-host.aci will still have 0.12.0 version.
Scenario:
rkt-0.12.0-1
.rkt-0.12.0-2
.The CAS will contain something like:
But the CAS does not see distro versioning, so it will be
coreos.com/rkt/stage1-host:0.12
for both0.12.0-1
and0.12.0-2
. So the new stage1 with the distro patch will not be executed after the dist-upgrade because the old version will still be in the CAS. Users will have to manually runrkt image rm sha512-6ae514fd1bfc
.The text was updated successfully, but these errors were encountered: