Bugzilla – Bug 1106839
Bogus file conflict when doing "zypper dup" on Tumbleweed
Last modified: 2018-09-03 17:00:50 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
This was reported by a forum user at:
I ran into the same conflict this evening, updating two Tumbleweed systems (also reported in forum post).
The file conflict was for liberation font definition files, with a conflict between "calibre" and "liberation-fonts".
In my case, I told zypper to continue anyway. After the update finished, I checked. And the liberation font definition files do not seem to be part of the calibre package. And the file date suggests that those files were never updated. So it looks as if the conflict message was bogus.
Other users reported no conflict for their updates. What I did differently, is I updated "zypper" separately before updating everything else. So I might have been using a newer "zypper" than the people who did not see conflict messages.
This looks like a "zypper" bug.
Reproducible: Didn't try
Created attachment 781633 [details]
Transcript of "zypper" update session
Had the same experience on my main TW installation (installed a year ago) when updating calibre to 3.30.0-1.1 that came with snapshot.
Uninstalled calibre and again installed it, this time no file conflicts.
I tested also on a VM with TW I had installed a week ago, on that one there were no file conflicts during upgrade.
(In reply to Neil Rickert from comment #0)
> Other users reported no conflict for their updates. What I did differently,
> is I updated "zypper" separately before updating everything else. So I
> might have been using a newer "zypper" than the people who did not see
> conflict messages.
I think it's the calibre package which 'fools' the file conflict check. Probably related to bug #1104597.
The file conflict check is run before the package installation actually starts and it takes the situation on disk into account. It looks like older calibre packages actually created a symlink
> /usr/share/calibre/fonts/liberation -> /usr/share/fonts/truetype
So the check sees /usr/share/calibre/fonts/liberation/LiberationMono-Bold.ttf
and /usr/share/fonts/truetype/LiberationMono-Bold.ttf denoting the same location on disk (i.e. possibly a file conflict).
Newer calibre packages however, manually remove those symlinks in their pretrans scripts
> pretrans scriptlet (using <lua>):
> path = "/usr/share/calibre/fonts/liberation"
> st = posix.stat(path)
> if st and st.type == "link" then
That's why the locations are not overwritten, but this is something the file conflict check can't see.
So whether you see this apparently bogus conflict depends on which calibre version is actually installed (the symlink still present on disk or not).
Thanks for the explanation.