DNF/RPM file conflict where there should be none (just mergeable folders)

Ask Fedora Ask in English
, ,
1

Hi,
when trying to install a rpm package for bricsCAD dnf/rpm says there are file conflicts.
But the reported file conflicts are actually folders and there are no conflicting files (just unique icons) within these folders.

details of this specific case

the actual install command:

# dnf install BricsCAD-V19.2.08-1-en_US.x86_64.rpm

Last metadata expiration check: 0:30:29 ago on Tue May 28 12:21:39 2019.
Dependencies resolved.
==============================================================================================================================================================================================================================================
 Package                                                    Architecture                                          Version                                                   Repository                                                   Size
==============================================================================================================================================================================================================================================
Installing:
 bricscadv19                                                x86_64                                                19.2.08-1                                                 @commandline                                                292 M

Transaction Summary
==============================================================================================================================================================================================================================================
Install  1 Package

Total size: 292 M
Installed size: 725 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
  file /usr/share/icons/hicolor from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package fedora-logos-30.0.2-1.fc30.x86_64
  file /usr/share/icons/hicolor/256x256 from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package fedora-logos-30.0.2-1.fc30.x86_64
  file /usr/share/icons/hicolor/256x256/apps from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package fedora-logos-30.0.2-1.fc30.x86_64
  file /usr/share/icons/hicolor/48x48 from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package fedora-logos-30.0.2-1.fc30.x86_64
  file /usr/share/icons/hicolor/48x48/apps from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package fedora-logos-30.0.2-1.fc30.x86_64
  file /usr/share/icons/hicolor/scalable from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package fedora-logos-30.0.2-1.fc30.x86_64
  file /usr/share/icons/hicolor/scalable/apps from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package fedora-logos-30.0.2-1.fc30.x86_64
  file /usr/share/icons/hicolor from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package hicolor-icon-theme-0.17-5.fc30.noarch
  file /usr/share/icons/hicolor/256x256 from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package hicolor-icon-theme-0.17-5.fc30.noarch
  file /usr/share/icons/hicolor/256x256/apps from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package hicolor-icon-theme-0.17-5.fc30.noarch
  file /usr/share/icons/hicolor/48x48 from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package hicolor-icon-theme-0.17-5.fc30.noarch
  file /usr/share/icons/hicolor/48x48/apps from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package hicolor-icon-theme-0.17-5.fc30.noarch
  file /usr/share/icons/hicolor/scalable from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package hicolor-icon-theme-0.17-5.fc30.noarch
  file /usr/share/icons/hicolor/scalable/apps from install of bricscadv19-19.2.08-1.x86_64 conflicts with file from package hicolor-icon-theme-0.17-5.fc30.noarch

Error Summary
-------------

relevant rpm contents:

$ rpm -q -l BricsCAD-V19.2.08-1-en_US.x86_64.rpm

[ ... many irrelevant files .. ]

/usr/share/applications/bricscadv19.desktop
/usr/share/doc/bricscadv19
/usr/share/doc/bricscadv19/changelog.Debian.gz
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-application-x-bricscadv19.png
/usr/share/icons/hicolor
/usr/share/icons/hicolor/256x256
/usr/share/icons/hicolor/256x256/apps
/usr/share/icons/hicolor/256x256/apps/bricscadv19.png
/usr/share/icons/hicolor/48x48
/usr/share/icons/hicolor/48x48/apps
/usr/share/icons/hicolor/48x48/apps/bricscadv19.png
/usr/share/icons/hicolor/scalable
/usr/share/icons/hicolor/scalable/apps
/usr/share/icons/hicolor/scalable/apps/bricscadv19.svg
/usr/share/menu/bricscadv19
/usr/share/mime/packages/bricscadv19.xml
/usr/share/pixmaps/bricscadv19.png

It doesn’t seem like its a problem with the packaging, because RPMs are really just glorified archives.?
Has anyone ever experienced this? As I understand this rpm normally shouldn’t show a conflict for folders, just the files within.

TL;DR:
rpm shows conflict where there is none
folders with mergeable content shown as conflicts

2

Hello @frhun. Welcome to the community! Please take a moment to go through the introductory posts in #start-here if you haven’t had a chance yet.

That is still a conflict. rpm keeps track of files and folders that each package includes so that when a package is removed, the folder can also be removed.

This does seem like a packaging error, with the specific case discussed here in the packaging guidelines here:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership

Is the spec file for their package available? That’ll tell us exactly what the issue is.

1 Like
3

Sadly, as it is closed source, i don’t have the spec.
Thank you for clearing the misunderstanding on my part, regarding how rpm works.

4

Ah—probably best to inform them, link to the packaging guideline, and hopefully they’ll fix it?

5

Already did, we’ll see what comes of it.

3 Likes