devicestate: disallow removal of snaps used in booting early
During the review of #6835 the question about the order of
the checks in canRemove for the active boot snaps was raised.
This PR improves snapsate.canRemove() so that it checks early
if the revision about to be removed is currently used for the
boot. Also adds some unit tests around this.
In practise its a bit of a corner case. A kernel/base used for
booting is usually active and we disallow removing of active
revisions anyway. The window is only when snapd refreshed
base/kernel but has not rebooted yet. But then it does not
accept commands right now until the reboot happend. But even
though we should be careful in canRemove().
packaging/fedora: force external linker to ensure static linking and -extldflags use
Go toolchain will use external linking only under specfiic conditions, such as
enabling PIE buildmode, using code that depends on CGO or an OGARCH/GOOS
unsupported by the internal linker.
Make sure that Go binaries are always using the external linker. This ensures
that external flags defined by distro policy, or package (such as -static) are
actually used.
Signed-off-by: Maciej Borzecki <email address hidden>
overlord/devicestate: introduce remodel kinds and contexts
different context implementations will be used depending on the kind
of remodel, and those will play the roles/implement as needed
snapstate.DeviceContext, storecontext.DeviceBackend and
registrationContext:
same brand/model, brand store => updateRemodel
this is just a contextual carrier for the new model
same brand/model different brand store => storeSwitchRemodel this
mediates access to device state kept on the remodel change, it also
creates a store that uses that and refers to the new brand store
different brand/model, maybe different brand store => reregRemodel
similar to storeSwitchRemodel case after a first phase that performs
re-registration where the context plays registrationContext's role
(NOT IMPLEMENTED YET)
