bundle-remove seems to remove content from /usr/lib/{kernel,modules}

[bryteise]

The bundle-remove sub-command appears to remove files from clr-boot-manager managed directories and does not call clr-boot-manager when kernel changes should be accounted for.

[icarus-sparry]

So the bug appears to be that bundle-remove is removing files that swupd is told not to manage, rather than bundle-remove not calling cbm - correct?

[bryteise]

I'd expect it to do both though not calling cbm at this point isn't really a problem as cbm wouldn't remove the last kernel of a type from the system anyway but that may be something that changes in the future.

[bryteise]

It would be handy if in the future swupd-client could pass the kernel type being removed so cbm would know it is okay to completely remove it from the system though.

[icarus-sparry]

I see the problem more as "what does it mean for a file to be marked as 'b' or 'g' in a Manifest?" I have taken it to mean "if asked to install it then do so, but it is not something that swupd should ever remove". This allows the flag to have a more general use than "this is a boot related file".

This is defensive, as this issue shows you do not want swupd to remove all your kernels. If we do want swupd to remove files rather than letting cbm do it, do we need to teach swupd that it must have at least one kernel package installed? Do we say it needs one unless it is in a container? How about someone using a container to build an image to boot on bare metal? One can add ever more complex scenarios! swupd will refuse to remove os-core for good defensive reasons as well.

[bryteise]

Well I'd always want cbm to manage files in /usr/lib/{kernel,modules} and avoid swupd being able to remove them at all.