http://bugzilla.opensuse.org/show_bug.cgi?id=1096803 http://bugzilla.opensuse.org/show_bug.cgi?id=1096803#c9 --- Comment #9 from Michael Andres <ma@suse.com> --- [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#L10...
[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#L23.... 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. -- You are receiving this mail because: You are on the CC list for the bug.