Comment # 9 on bug 1096803 from Michael Andres

[continue - cut'n'paste lost some lines]
Reloading the target after commit:

> [zypp] TargetImpl.cc(load):998 adding /var/cache/zypp/solv/@System/solv to pool(@System)
> [zypp] TargetImpl.cc(load):1022 adding /var/cache/zypp/solv/@System/solv to system
> [zypp] TargetImpl.cc(load):1074 ZConfig::instance().apply_locks_file = 1
> [zypp] TargetImpl.cc(load):1075 ZConfig::instance() locksfile = /etc/zypp/locks
> [zypp] HardLocksFile.h(data):64 0xb997820 -- 1
> [zypp] TargetImpl.cc(load):1079 0
> [zypp] TargetImpl.cc(load):1084 ZConfig::instance().apply_locks_file DONE

So this empty commit actually resets the locks in the pool to be empty (the `0`
in the one but last line `TargetImpl.cc(load):1079`).




Now the workflow continues and actually loads target and repos:

> [Pkg] modules/OneClickInstallWorkerFunctions.rb:196 Pkg Builtin called: ResolvableInstallRepo
> [Pkg] modules/OneClickInstallWorkerFunctions.rb:220 Pkg Builtin called: TargetInit
> [zypp] TargetImpl.cc(buildCache):850 Read cookie: /var/cache/zypp/solv/@System/cookie{- 0644 0/0 size 52}
> [zypp] TargetImpl.cc(buildCache):857 Read cookie: /var/cache/zypp/solv/@System/cookie says: uptodate
> [zypp] TargetImpl.cc(load):992 New cache built: false, force loading: true
> [zypp] TargetImpl.cc(load):998 adding /var/cache/zypp/solv/@System/solv to pool(@System)
> [zypp] TargetImpl.cc(load):1022 adding /var/cache/zypp/solv/@System/solv to system
> [zypp] TargetImpl.cc(load):1074 ZConfig::instance().apply_locks_file = 1
> [zypp] TargetImpl.cc(load):1075 ZConfig::instance() locksfile = /etc/zypp/locks
> [zypp] HardLocksFile.h(data):64 0xb997820 -- 1
> [zypp] TargetImpl.cc(load):1079 0
> [zypp] TargetImpl.cc(load):1084 ZConfig::instance().apply_locks_file DONE
> [zypp] TargetImpl.cc(updateFileContent):724 updating '/var/lib/zypp/LastDistributionFlavor' content.
> [zypp] TargetImpl.cc(load):1090 Target loaded: 4007 resolvables

The locks however stay empty due to the commit before.



The reason why people don't lose their locks, but get complex locks exapanded,
is in yast2-pkg-bindings:
https://github.com/yast/yast-pkg-bindings/blob/master/src/Target_Load.cc#L101

> [Pkg] Target_Load.cc(TargetInitInternal):100 Reading locks from /etc/zypp/locks
> [locks] Locks.cc(readAndApply):105 read and apply locks from /etc/zypp/locks

I'm not sure why YAST on it's own explicitly loads /etc/zypp/locks? A few lines
above (L85) the target is loaded, and this also loads the locks into the pool.
In 'ordinary' workflows the action here is superfluous, as you load the locks a
2nd time.

In ONECLICK however this is why we don't lose the locks after the empty commit,
BUT the old '[locks]' API adds locks expanded (which does not matter if the
tagret alredy saw the original locks).



Then ONECLICK commits the package install, which writes back the (expanded)
locks file:

> [Pkg] modules/PackageSlideShow.rb:404 Pkg Builtin called: SourceGeneralData
> [Pkg] modules/OneClickInstallWorkerFunctions.rb:226 Pkg Builtin called: PkgCommit
> [zypp] TargetImpl.cc(commit):1119 TargetImpl::commit(<pool>, CommitPolicy( DownloadInHeaps syncPoolAfterCommit ))
> [zypp] TargetImpl.cc(commit):1145 Todo: CommitResult  (total 1, done 0, error 0, skipped 1, updateMessages 0)
> [zypp] HardLocksFile.h(setData):81 0xb997820 -- 1
> [zypp] HardLocksFile.cc(store):59 Wrote /etc/zypp/locks{- 0644 0/0 size 615293}


And similar to TargetInitInternal, TargetFinish would write back the locks file
a second time here:
https://github.com/yast/yast-pkg-bindings/blob/master/src/Target_Load.cc#L238.
Not sure how YAST can be sure that the pool does not contain any rejected
changes, which should not be synced back to the system. Called after a
successful commit however it's just overhead, as commit already did the same.