Comment # 17 on bug 1199895 from Michael Andres

(In reply to Jonathan Kang from comment #16)
> ... I think the problem is that they gained "ToBeInstall" status 
> even they were locked, after doing a  "resolver->doUpgrade()"
> for tumbleweed.

I can hardly imagine how this should happen in PK only.

If a locked package has to be amended, the resolver will raise the problem and
someone has to select the appropriate solution ('removing the lock' rather than
'drop the jpb'). 


Is someone able to reproduce it or has a system where this happened?

If resolver->doUpgrade() (DUP) was called and the result is committed, zypp
should auto-write a testcase. The testcase is named
/var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss (date the dup was performed). The
pk_backend_zypp[_#] log should also show a line like 
> ... [zypp] Testcase.cc(createTestcase):388 createTestcase done at /var/log/updateTestcase-2022-07-07-11-06-04
if a testcase was written.

If one is available somewhere, it should reveal what happenend during DUP. The
corresponding pk_backend_zypp log would be helpfull as well.