We should not allow zopen dependencies like jq/curl to be removed

[IgorTodorovskiIBM]

Or provide a backup location in case they are removed:

$  zopen remove jq
Removing package: jq
- Checking status of package 'jq'
- Package installed, unmeshing from system
- Removing metadata file to mark uninstall
- Breaking link from current to versioned
- Checking for obsoleted files in /home/itodoro/zopen/usr/ tree from jq
- Checking 22 potential links
- Complete
- Checking 11 dir links
- Removing profiled entry
Successfully removed: jq

$ zopen install jq
- Querying remote repo for latest package information
jq: getReposFromGithub 3: /home/itodoro/projects/meta/bin/zopen-install 623: FSUM7351 not found

[DevonianTeuchter]

In a similar vein, removing meta itself might be interesting! There should be the bootstrap versions still available so we could fallback to those but perhaps a flag in the metadata marking something as non-removable would be simpler

[MikeFultonDev]

This seems an important one since someone could brick their zopen by removing curl, meta, jq. Can we go with a simple starter where we record the tools that are pre-packaged and just prevent them from being removed? People should still be able to clean extra ones. @DevonianTeuchter @IgorTodorovskiIBM thoughts?

[IgorTodorovskiIBM]

We could add a ".donotdelete" hidden file to the pre-reqs and check for its existence prior to deleting

[DevonianTeuchter]

The hidden file approach or metadata tag to mark as non-deletable is fairly easy to implement. However, what happens if we update the base release (for a CVE for example)? The "do-not-remove" tagged version would need to be removed and replaced (or at least now be cleanable since the new version would be the DNR). When we update, we need a mechanism to remove the tag from the previous DNR version - otherwise we start to leak old versions...