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.)
Related
I'm faced with a problem. I don't know what to do next:
asterisk: error while loading shared libraries: libjansson.so.4:
cannot open shared object file: No such file or directory
First try just run
ldd
If not help, try find libjansson.so.4. If found, ensure it is in path. If not found, try libjansson.so*(any other version) and do symlink to libjansson.so.4.
First have the required release of jansson :
untar is and run (if already installed then skip this part)
./configure
make
make check
make install
ldconfig creates the necessary links to the runtime libraries, you need to create a config file and add the path of the library of your choice.
echo “/usr/local/lib” > /etc/ld.so.conf.d/usr_local.conf
/sbin/ldconfig
reference : this
I'm trying to build R.3.3.2 on a SuSE Linux server. It is a routine configure/make/install kind of setup.
It relies on some libs/headers that are either missing on my server or are older than required versions. As I run ./configure I get messages like:
configure: error: "liblzma library and headers are required"
I can download and build the missing packages in my home dir (with --prefix=$HOME/packages) as there is enough guidance on R website, but will appreciate guidance in how to build the final target (i.e., R).
If I build with packages installed in my home dir (by updating LD_LIBRARY_PATH) then everyone has to include my packages/ to their paths.
OTOH I am reluctant to add all these new packages to /usr/lib64/ because I am unsure version change impact on other programs. My search path shows:
$ gcc -Xlinker --verbose 2>/dev/null | grep SEAR | sed -e 's/SEARCH_DIR//g'
("/usr/x86_64-suse-linux/lib64"); ("/usr/lib64"); ("/usr/local/lib64"); ("/lib64"); ("/usr/x86_64-suse-linux/lib"); ("/usr/local/lib"); ("/lib"); ("/usr/lib");
which shows that a standard lib version is going to be picked before /usr/local/lib64
So my question is how does one generally resolve this kind of issue?
It also made me think perhaps I should static link only these new packages. Maybe it's a wrong kind of thought :| but I am also unclear what command line options for ./configure to do this. I will appreciate your help. Thanks a lot.
It is checking for dependencies so we need to install
the xz-5.2.2.tar.gz file first which you will get from this site:
http://tukaani.org/xz
Then go to Download Directory and execute these commands
tar xzvf xz-5.2.2.tar.gz
cd xz-5.2.2
./configure --prefix=$HOME/packages
make -j3
make install
Hope it will work for further any help please post your queries with proper error snapshot
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 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
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.