Open dcookspi opened 1 year ago
Makes sense to me - I've been eyeing this install
command for a re-vamp as well since we are looking at workflows which would require incremental updates to old solves and this command can only really add new compatible packages, but has a hard time with making any changes to existing packages such as changing the build or making downgrades
The
spk install ...
command adds packages to the current runtime by adding requests for the new packages to requests for the existing packages. Then is solves for all of them and replaces the runtime's stack with the layers from the resolved solution. However in doing so, it loses any additional spfs layers/refs/digests that were in the runtime but did not come from the original solution's packages. Any edits in the upperdir are retained though.This means someone who has entered a runtime via spk, has done some editing, has
spfs commit
ted a layer or platform, carried on editing/working, and then wants to include another package will lose their extra layer/s from the runtime. Getting their additional layer/s back on top of the runtime stack is convoluted with the existing commands.It seems like
spk install ...
should replace the layers for the old packages with the layers from the new solution, but it should leave any other layer/s (really spfs refs) in the stack as they are (at the top of the stack).Steps to replicate: