Case description:
We are using oc-mirror to create a 2 .tar archives with a set of operators (with a well defined version for each one).

Here is the command line used to generate the first archive (the corresponding imageset-config-01.yaml file has been attached to the Jira comment):
```
oc mirror --config=imageset-config-01.yaml file:///local/oc-mirror/working-dir
```

Here is the command line used to generate the second archive (the corresponding imageset-config-02.yaml file has been attached to the Jira comment):
```
oc mirror --config=imageset-config-02.yaml file:///local/oc-mirror/working-dir
```

=> This way, we got 2 .tar archives generated by oc-mirror: mirror_seq1_000000.tar and mirror_seq2_000000.tar

Cluster installation and initial configuration

• We use this first .tar file to populate our private registry, install our cluster and perform its initial configuration.

Here is the command line used to upload the .tar file content on our private registry:
```
oc mirror --from=./mirror_seq1_000000.tar docker://mirror-registry/oc-mirror"
```

Cluster OperatorHub update (Adding operator named: "openshift-gitops-operator" )
Once our cluster is well configured, we use a second .tar archive (generated thanks to oc-mirror too) to update our private registry with this additional operator : openshift-gitops-operator

Test n°1 (--skip-pruning option not used)
As we freeze the operators versions in the imageset YAML files, and both imageset YAML files are identicall (except for the openshift-gitops operator), we expected oc-mirror not to prune any images from the registry and simply add images related to the newly added operator.
Unfortunately, when we are running the oc-mirror command used to populate our registry with the second .tar file, an error occured and the oc-mirro command is failing.

Here is the command line command line used to upload the second .tar file content on our private registry:
```
oc mirror --from=./mirror_seq2_000000.tar docker://mirror-registry/oc-mirror
```
=> oc-mirror initiates deletion of multiple images and, finally, raises multiple VIOLATE_FOREIGN_KEY_CONSTRAINT errors and crashes (the full oc-mirror logs can be found in the attached file named oc-mirror-error-on-upload-when-skip-pruning-not-used.log).

Test n°2 (--skip-pruning option used)
As it appears that the oc-mirror command failed due too unexpected images deletion, we performed another test on which we used the --skip-pruning option when we executed the second oc-mirror command line.

Here is the command line command line used to upload the second .tar file content on our private registry:
```
oc mirror --from=./mirror_seq2_000000.tar docker://mirror-registry/oc-mirror --skip-pruning
```
=> oc-mirro command is successful this time.
=> We configured our cluster in order to reflect the private registry update and being able to see the newly added operator in the OperatorHub.

Unfortunately, when we compare the 2 sets of images present in the index of the redhat-operator catalog (before and after the addition of the openshift-gitops-operator), we observed that some images have been removed from the index. That's not expected as we are simply adding a new operator (cf. attached files: indexes-dump-1.log (before update) and indexes-dump-2.log (after update).
{}Note{}: The images removed from the index are still present in our registry (thanks to the usage of the --skip-pruning option)

Case request:
Could you help us to solve this issue and tell us which steps we are supposed to go through, on our disconnected cluster, to fully control the versions of the operators that we want to successively add to our cluster's OperatorHub without impacting the other already installed operators images ?