hansvand / winff

Automatically exported from code.google.com/p/winff
0 stars 0 forks source link

RPM Package tries to own directories it shouldn't #186

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. See below

What is the expected output? What do you see instead?
Program installs properly

What version of the product are you using? On what operating system?
winff 1.4.3 on Fedora 18 x86_64

Please provide any additional information below.

Additionally, on x86_64 systems the library directory is /usr/lib64 not 
/usr/lib as Fedora is multi-lib.

# yum install http://winff.googlecode.com/files/winff-1.4.0-3.x86_64.rpm
Loaded plugins: langpacks, presto, refresh-packagekit
winff-1.4.0-3.x86_64.rpm                                 | 2.2 MB     00:01
Examining /var/tmp/yum-root-1q0J6O/winff-1.4.0-3.x86_64.rpm: 
winff-1.4.0-3.x86_64
Marking /var/tmp/yum-root-1q0J6O/winff-1.4.0-3.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package winff.x86_64 0:1.4.0-3 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package      Arch          Version          Repository                    Size
================================================================================
Installing:
 winff        x86_64        1.4.0-3          /winff-1.4.0-3.x86_64        7.6 M

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

Total size: 7.6 M
Installed size: 7.6 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test

Transaction Check Error:
  file / from install of winff-1.4.0-3.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64
  file /usr/bin from install of winff-1.4.0-3.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64
  file /usr/lib from install of winff-1.4.0-3.x86_64 conflicts with file from package filesystem-3.1-2.fc18.x86_64

Original issue reported on code.google.com by hobbes1...@gmail.com on 22 Jan 2013 at 7:08

GoogleCodeExporter commented 8 years ago
Thanks for reporting this issue.

As we have hardly an idea how a RPM should look like, we just create it with 
the "alien" program, starting with the Debian package that I do know how to 
create properly.

Could you test the 1.5.0 package and see if the problem is also there. If that 
is the case, you could file a bug against "alien".

Original comment by poipodec...@hotmail.com on 22 Jan 2013 at 8:11

GoogleCodeExporter commented 8 years ago
Yes. I still tried to own / and /bin. No files were put in /usr/lib but I only 
tried the gtk interface, not the qt one. In looking at what files are actually 
placed in /usr/lib, "/usr/lib/mime/packages/winff" I don't think this has any 
real meaning on Fedora/RHEL (or likely Suse). Additionally I'm not sure what 
/usr/share/menu does either...

I think native packaging would be best and I'm working on packaging it for 
myself but it's slow going due to a lack of automatic install. Perhaps once 
I've got something tested they can be used instead? If you need to verify I'm 
an actual Fedora packager try sending an email to hobbes1069@fedoraproject.org. 
It should get redirected to my direct email address but I've actually never 
used the forwarding before. 

I'm surprised someone hasn't packaged it for Fedora (via RPM Fusion) already. 
It doesn't seem to contain any bundled libraries that I can see which is the 
usual problem.

Original comment by hobbes1...@gmail.com on 22 Jan 2013 at 8:56

GoogleCodeExporter commented 8 years ago
Sending you a private message right now. Yes, your effort is very welcome.

Original comment by poipodec...@hotmail.com on 22 Jan 2013 at 9:18

GoogleCodeExporter commented 8 years ago
Instruction for the new style RPM's can be found here: 
http://code.google.com/p/winff/wiki/FedoraInstallation

Original comment by poipodec...@hotmail.com on 17 Mar 2013 at 10:56