English
Ask Your Question
1

File conflict for installing a package with "Filesystem"

asked 2013-12-16 22:04:02 +0000

mikesalzap gravatar image

updated 2014-09-28 17:10:41 +0000

mether gravatar image

Hello, i have been trying to install a program to see and download from iTunesU, Tunesviewer, and it says that there is a conflict with some files "filesystem-3.2-13.fc19.x86_64", and i don't know what to do to solve it. I am not to new to linux; but i have never had this problem. Any ideas how to solve it?

# yum localinstall tunesviewer-1.4.noarch.rpm
Loaded plugins: langpacks, refresh-packagekit
Examining tunesviewer-1.4.noarch.rpm: tunesviewer-1.4-2.noarch
Marking tunesviewer-1.4.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package tunesviewer.noarch 0:1.4-2 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package           Arch         Version     Repository                     Size
================================================================================
Installing:
 tunesviewer       noarch       1.4-2       /tunesviewer-1.4.noarch       192 k

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

Total size: 192 k
Installed size: 192 k
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test


Transaction check error:
  file / from install of tunesviewer-1.4-2.noarch conflicts with file from package filesystem-3.2-13.fc19.x86_64
  file /usr/bin from install of tunesviewer-1.4-2.noarch conflicts with file from package filesystem-3.2-13.fc19.x86_64

Error Summary
-------------
edit retag flag offensive close merge delete

3 answers

Sort by ยป oldest newest most voted
2

answered 2013-12-17 06:30:23 +0000

Ahmad Samir gravatar image

updated 2013-12-17 06:35:23 +0000

There was/is a similar problem with google-earth - another 3rd party rpm http://forums.fedoraforum.org/showthread.php?p=1650497#post1650497 .

One solution is to use the rpmrebuild command and edit the rpm: - Install rpmrebuild, then edit the rpm:

rpmrebuild -pe tunesviewer-1.4-2.noarch.rpm

this should open the spec file in vi. If you want to use any other text editor run e.g. 'export EDITOR=/usr/bin/kwrite', before running the rpmrebuild command.

  • In the '%files' section remove these lines:
%dir %attr(0755, root, root) "/"
%dir %attr(0755, root, root) "/usr"
%dir %attr(0755, root, root) "/usr/bin"
%dir %attr(0755, root, root) "/usr/share"
%dir %attr(0755, root, root) "/usr/share/applications"
%dir %attr(0755, root, root) "/usr/share/doc"
%dir %attr(0755, root, root) "/usr/share/icons"
%dir %attr(0755, root, root) "/usr/share/icons/hicolor"
%dir %attr(0755, root, root) "/usr/share/icons/hicolor/scalable"
%dir %attr(0755, root, root) "/usr/share/icons/hicolor/scalable/apps"

save and close the editor, and follow the prompts in the terminal.

That should make the rpm installable.

edit flag offensive delete link more

Comments

1

That should fix it, but please report the problem to whoever wrote the tunesviewer RPM; it should not be conflicting with the filesystem package - it's a packaging bug if it's designed to install on Fedora.

sandeen ( 2013-12-28 19:36:58 +0000 )edit
1

answered 2014-03-09 17:48:12 +0000

mykelalvis gravatar image

IIRC, these packages are produced by processing the .deb file with alien. The issues are with what the alien package processor does. I don't think it's precisely a bug, although it clearly produces buggy RPMs.

The rpmrebuild is probably the only solution that produces a good RPM until alien stops doing this (which it may already have).

edit flag offensive delete link more
0

answered 2013-12-16 23:32:45 +0000

nonamedotc gravatar image

updated 2013-12-16 23:34:22 +0000

It appears that there are some serious packaging issues with this rpm!

rpm -qlp tunesviewer-1.4.noarch.rpm 
/
/usr
/usr/bin
/usr/bin/tunesviewer
/usr/share
/usr/share/applications
*[ ... ]*
/usr/share/doc
*[ ... ]*

Only filesystem should provide those high-in-the-hierarchy directories. It does not look like they have tarballs ... I am not sure what would be best, sorry!

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Use your votes!

  • Use the 30 daily voting points that you get!
  • Up-vote well framed questions that provide enough information to enable people provide answers.
  • Thank your helpers by up-voting their comments and answers. If a question you asked has been answered, accept the best answer by clicking on the checkbox on the left side of the answer.
  • Down-voting might cost you karma, but you should consider doing so for incorrect or clearly detrimental questions and answers.

Stats

Asked: 2013-12-16 22:04:02 +0000

Seen: 15,590 times

Last updated: Mar 09 '14