I have downloaded Google earth and am trying to install it on Fedora 19. I am getting the error
google-earth-stable-7.1.2.2041-0.x86_64 conflicts with file from package filesystem-3.2-13.fc19.x86_64
Not quite sure if this needs answering but I guess the question is not closed.
The problem is that the rpm includes the 'install' of /usr/bin/ which is of course nonsense. To fix this do:
Make sure you have rpmrebuild
Run (for instance in my case) rpmrebuild -ep /home/geek/Downloads/google-earth-stable_current_x86_64.rpm
Scroll down and remove line: %dir %attr(0755, root, root) "/usr/bin"
Save / exit the editor .. after a while you see rpmrebuild exiting saying something like: result: /root/rpmbuild/RPMS/x86_64/google-earth-stable-7.1.2.2041-0.x86_64.rpm
Install that rpm and your done
I don't know if this might resolve your problem, but I had the same problem and I find this to fix...
Source:
www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-rpm-using.html
10.2.2.2. Conflicting Files
If you attempt to install a package that contains a file which has already been installed by another package, the following is displayed:
Preparing... ########################################### [100%]
file /usr/bin/foo from install of foo-1.0-1 conflicts with file from package bar-2.0.20
To make RPM ignore this error, use the --replacefiles option:
rpm -ivh --replacefiles foo-1.0-1.i386.rpm
Related
I have an RPM I am making and this is in a very controlled environment so let's also assume it is safe to allow another RPM package to overwrite certain files contained from the original RPM package.
I know from experience if you try to install an RPM package that overwrites another RPM packages file's you get a warning that there is a conflict and the install fails (yes you can do some command line hacking but that is not ideal for the situation).
Is there any way through the original RPM packages spec file that you can specify these files are not part of the package they can be overwritten by another RPM package or is that just strictly prohibited from ever happening?
Is there any way through the original RPM packages spec file that you can specify these files are not part of the package they can be overwritten by another RPM package or is that just strictly prohibited from ever happening?
You can use %ghost directive for this purpose.
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
I am trying to install the GCC 4.7 in linux environment; using following command:
zypper install *.rpm
in a directory containing:
libgcc_s1-4.7.2_20130108-0.17.2.x86_64.rpm
libmpc2-0.8.2-1.7.1.x86_64.rpm
libstdc++6-4.7.2_20130108-0.17.2.x86_64.rpm
Following error shows up:
error: Failed to read /usr/lib/rpm/rpmrc: Is a directory.
Repository named '_tmpRPMcache_' already exists. Please use another alias.
I am not able to find the tmpRPMcache where it is located so that I I try to find the issue. Any help is highly appreciable.
It seems that - when installing rpm files not from a repository - zypper uses a "temporary" repository for those rpms. For some reason that repository already exists. Probably you can find that file in /etc/zypp/repos.d/ and remove it safely (make a copy just to be sure):
mv /etc/zypp/repos.d/_tpmTPMcache_.repo{,.bak}
(I'm not 100% sure of the exact filename; but I suspect you will find it there.)
I am working with RPM package manager for about a month now. Currently I want to use rpm -U to upgrade already existing content from previous RPM execution but I need to know the rpm package location on the file system.
The only way I can think of is searching whole file system for rpm name in %pre script but I would really like to avoid that option. Is there any way to get the path of the rpm package (package can be anywhere on the system) as a variable inside the spec file (%pre and %post script). Hope I explained my issue clearly enough.
Any help or proposal is welcome.
There isn't one location (or path) where a package is installed,
so I'm not sure what you are asking.
The files that are installed by a installed rpm package called "foo"
can be displayed with
rpm -ql foo
There is no common prefix on the paths except "/" in general.
I created a binary package with this command:
dpkg-deb --build -z9 -Zlzma $(DEB_SRC_DIR) $(DEB_DEST_DIR)
and install it on my Ubuntu 12.04 with this command:
sudo dpkg -i /path/to/package
The contents of the package I think are irrelevant.
Despite the sudo command the files in the installation directory belong to the current user and not to root as I expected.
How can I fix that?
Try to run the dpkg-deb command with fakeroot:
`fakeroot dpkg-deb ...`
(This will only help if the files in the source directory already have the correct ownership, which they probably dont. The problem you're actually trying to solve here, is to create an archive with files in it that belong to user root, which is where fakeroot theoretically helps.)
Let me say though, that what you are doing is not the best way for creating a binary package (far from it).
Instead, create a debian/ directory with dh_make (from the dh-make package), and edit the control file and changelog accordingly. You also need a file debian/install that lists what files you are installing and where they should go. There are various guides on the net (and on Stack Overflow) that explain this process. For example, look at the Debian New Maintainers' Guide.
You can then use dpkg-buildpackage to create a real, standard-conforming Debian package with your files in a reproducible way.
dpkg-deb is a low-level tool for manipulating existing deb files; it's not meant to be used for package creation.
I am building a bootable ISO to be used to install a Linux image (Oracle Linux, 5.8). This is using anaconda with a kickstart file to select the packages to be loaded. Some of these packages are failing with dependency problems in their %post section.
Eg, this is seen in /root/install.log after the installation is complete:
Installing thirdparty-tools-1.00-09.noarch
/var/tmp/rpm-tmp.97891: line 1: ln: command not found
/var/tmp/rpm-tmp.97891: line 2: ln: command not found
/var/tmp/rpm-tmp.97891: line 3: ln: command not found
/var/tmp/rpm-tmp.97891: line 4: ln: command not found
error: %post(thirdparty-tools-1.00-09.noarch) scriptlet failed, exit status 127
I'm trying to find out if it is possible to control/override the package ordering, without editing any RPMs to add dependencies. I've been looking through the anaconda / kickstart documentation (https://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_3._Package_Selection), and searching extensively elsewhere, so I think that the answer is actually 'no, you can't do this'. Which would be a shame.
The problem is that I am trying to include various third-party RPMs, which are not under my control and which have been digitally signed. These include some processing in a %post section. This processing requires some standard Linux commands, eg 'ln', 'touch', etc, which are supplied within the coreutils package. The third-party package does not currently include a dependency on the coreutils package, though obviously it should really. Anaconda uses its own partial ordering algorithm to choose what order to install these packages, and the third-party packages are being installed before the coreutils package. Obviously, the proper solution is to get these RPMs fixed by the third-party; however, this is likely to take too long.
I was hoping that their might be some hidden / un-documented option for the kickstart file, which could add in extra dependencies. Ideally, I'd like to be able to add something like this to the %packages section:
%packages
#admin-tools
#base
#core
#system-tools
thirdparty-tools
# We would like to add some magic command to indicate a missing dependency
thirdparty-tools dependson coreutils
So, my question is: Is it possible to control or override the package ordering without editing any RPMs to add dependencies?
Very many thanks for any help.
If you can't get the source RPM, you can use rpmrebuild to re-create the RPM:
rpmrebuild -e -n -d . -p thirdparty-tools-1.00-09.noarch
This will bring up a re-created spec file in your default editor, where you can make changes to the requires lines. Also, you may want to change the package name too, so that your re-built version is differentiated from the upstream vendor's version (I usually append "-local" to the package name).
Your package "thirdparty-tools" needs to specify all of its requirements. If you can get a SRPM of this package, you can modify the spec to indicate that you need coreutils, bash, etc in your package.
If you can't modify this package at all, your best option is to create a wrapper package that has the necessary requirements. Just use your favorite editor to create a file "thirdparty-tools-installer.spec" and ensure you include coreutils as a requirement as well as "thirdparty-tools". You can refer to rpm.or for more information http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html
Lastly, you can just do yum -y install thirdparty-tools in the %post section of Kickstart. It's uglier for sure, but it will probably work.