Bug 1070440 - rpm fails to update package - conflicting files
Summary: rpm fails to update package - conflicting files
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 20
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-26 20:32 UTC by hannes
Modified: 2014-02-27 07:30 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-02-27 07:30:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
failure when installing (55.79 KB, text/plain)
2014-02-26 20:32 UTC, hannes
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.