Bug 1070440

Summary: rpm fails to update package - conflicting files
Product: [Fedora] Fedora Reporter: hannes <johannes.lips>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: ffesti, jzeleny, novyjindrich, packaging-team-maint, pknirsch, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-27 07:30:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
failure when installing none

Description hannes 2014-02-26 20:32:03 UTC 
Created attachment 868186 [details]
failure when installing

Description of problem:
I am in the process of upgrading an already existing package elementary-xfce-icon-theme.
When I try to update the installed package with my locally built package I get the attached rpm output.
An updated version of the package can be found at:
http://repos.fedorapeople.org/repos/hannes/freemind-1.0.0/fedora-20/noarch/
http://hannes.fedorapeople.org/elementary-xfce-icon-theme-0.4-1.fc20.src.rpm


Version-Release number of selected component (if applicable):
rpm-4.11.2-2.fc20.x86_64
yum-3.4.3-132.fc20.noarch

How reproducible:
Always.

If you need further information, just let me know.
Comment 1 Panu Matilainen 2014-02-27 07:30:19 UTC 
You're replacing a symlink to a directory with a directory, the first conflict is rpm's way of telling you it can't do that:

file /usr/share/icons/elementary-xfce-darker/actions/16 from install of elementary-xfce-icon-theme-0.4-1.fc20.noarch conflicts with file from package elementary-xfce-icon-theme-0.3-3.fc20.noarch

The rest are file conflicts within the package itself. It might seem strange but that is entirely possible in presence of directory symlinks, in this its presumably the above symlink, which when present on the disk would cause the newer version to conflict with itself.