Comment # 11 on bug 1183711 from Benjamin Zeller

(In reply to Fabian Vogt from comment #10)
> > https://w3.suse.de/~fvogt/boo1183711core.xz
> > This time it didn't crash in libsolv, but the memory corruption caused a
> > "stack level too deep" error in ruby and then it aborted in malloc_printerr.
Yeah then it won't be too helpful :/. 

> > Before copy and link:
> > 
> > lr-x------ 1 root root 64 M���r 31 10:05 27 ->
> > /mnt/var/cache/zypp/solv/@System/solv
> > lr-x------ 1 root root 64 M���r 31 10:00 28 ->
> > /var/cache/zypp/solv/openSUSE-Leap-15.3-1_0/solv
> > 
> > After copy and link:
> > 
> > lr-x------ 1 root root 64 M���r 31 10:05 27 ->
> > /mnt/var/cache/zypp/solv/@System/solv
> > lr-x------ 1 root root 64 M���r 31 10:00 28 ->
> > /var/cache/zypp/solv/openSUSE-Leap-15.3-1_0/solv (deleted)
> > 
> > So the 15.3 solv file got unlinked and @System/solv got overwritten!
So that means libzypp already had a file in the destination cache and its
overwritten? 
Maybe we should rethink the order in which this is happening here.
> > 
> > Excluding @System from the copy prevents the crash. It might work to remove
> > /mnt/var/cache/zypp/ before the copy, so that the open cache isn't modified.
> 
> Yep, that seems to work. I opened a PR:
> https://github.com/yast/yast-packager/pull/561
> Reassigning back to YaST.
> 
> > Or cp could be used with --remove-destination.
> 
> I chose the explicit removal as this avoids mixing local and destination
> caches completely. If it's an issue that caches of other repos are also
> cleared, then the cp switch could be used instead.

Still a bit concerned about that, in a running transaction ripping the file
away from under libzypp/libsolv sounds like a bad idea. And with running
transaction I mean somewhere between loading the target and doing a commit.

I would still like to get a ok from mlandres and mls about this.