Bug 1106839 - Bogus file conflict when doing "zypper dup" on Tumbleweed
Bogus file conflict when doing "zypper dup" on Tumbleweed
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: libzypp
Current
x86-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-09-02 02:08 UTC by Neil Rickert
Modified: 2018-09-03 17:00 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Transcript of "zypper" update session (2.79 MB, text/plain)
2018-09-02 02:10 UTC, Neil Rickert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neil Rickert 2018-09-02 02:08:02 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build Identifier: 

This was reported by a forum user at:
https://forums.opensuse.org/showthread.php/532899-

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
Comment 1 Neil Rickert 2018-09-02 02:10:30 UTC
Created attachment 781633 [details]
Transcript of "zypper" update session
Comment 2 Michiel Janssens 2018-09-02 11:10:32 UTC
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.
Comment 3 Michael Andres 2018-09-03 10:36:18 UTC
(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
>   os.remove(path)
> end
> ...

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).
Comment 4 Neil Rickert 2018-09-03 17:00:50 UTC
Thanks for the explanation.