Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am running sles10sp3 on two different vm's. I am trying to find the same rpm's as are installed on one of the vm's, so that I can install the same rpm's on the other vm. Is there any way to simply copy them from one vm to another (or in general copy all the .rpm's off SLES)? This has started with me trying to find a ruby 1.8.4 rpm and not having any luck, but there are a bunch of other rpm's I need to find as well.
Once a RPM package is installed, there is not enough information left on the system to reconstruct the RPM.
You can use "rpm -qa" to list all of the packages (and their versions) on each system, and you can "diff" those lists. But to actually install a specific version of a specific package, you will have to find (or search for) an actual copy of the actual RPM.
You can also use "rpm -ql " to enumerate the files associated with the RPM. But RPMs can also have pre-installation and post-installation scripts, so you cannot simply "tar up" the files and move them over.
In short I do not think there is any way to do what you want to do.
Also this is off-topic for StackOverflow. :-)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
So the question is pretty straightforward. My idea is pretty simple, just copy the executable under /usr, then add the path into the environment path variable.
Is that all? Or do I miss something?
Sorry if this question is dumb, I'm not a noob to Linux but I am not sure about this question.
I mean it's pretty much gonna work but I don't know if it's the "standard" way to do it.
Don't write an install script at all.
Package it for the popular package managers or have someone package it for you.
The most popular are
dpkg/apt used by Debian, Ubuntu, Linux Mint and friends
rpm/yum used by RedHat Linux, openSUSE and fiends
pacman used by ArchLinux and fiends
emerge used by Gentoo and fiends
Yep, all you need to do is copy the executable (as long as you have no dependencies). If you put it in /usr/bin, you don't need to modify the path, as it's in there by default.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I don't want to install multiple instances of perl.
How can I upgrade my Perl to latest version or delete existing Perl installation and install a new version of Perl in Ubuntu 14.04.
After new installation, will it conflict with older installation files.
I'd do it like this:
wget http://www.cpan.org/src/5.0/perl-5.22.1.tar.gz
tar xvfz perl-5.22.1.tar.gz
cd perl-5.22.1 && ./Configure -Duseithreads -des && make && make test && make install
/usr/local/bin/cpan -u
This puts a source build of perl in /usr/local/bin
Then check your path has /usr/local/bin in it, and if you want typing perl to run your new perl, ensure it's in front of /usr/bin (this is a fairly common scenario, but I can't say for sure if that applies.
Whilst you say you don't want to install multiple perl versions - this is a bad idea.
perl is distributed as part of your operating system. Packages depend upon it, and the particular version. You cannot tell what you might break by altering versions - not least because the way perl handles certain things does change between versions (like hashes).
Messing around with /usr/bin/perl is a road to some future pain (not least - it makes an 'update' of your OS annoyingly difficult, because you can no longer use the package manager without a bit of hackery)
If you REALLY REALLY want to do that you can set -Dprefix= in your Configure options. But as a sysadmin of 15 years experience, I can tell you - no good will come of it, you will break your OS in a variety of minor, but cumulatively really annoying ways. (And maybe some bigger ways)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
This is more of a curiosity question, but I feel it's worth asking.
Frequently when downloading software on Linux, I'm used to using sudo apt-get install [package] or whatever package manager is available, but for some projects like sbt, they don't have a repository (so I can't just type sudo apt-get install sbt and use it out of the box). I have to download the binaries and add them to PATH.
What I like to do is create a directory specific to programs like sbt, specifically ~/Programs. I move the unpacked directory into it, and add it to PATH. However, I'm always a little wary about moving the binary out of the directory it came in, so I don't want to remove it.
Is there such a thing as a recursive PATH variable, so that not only ~/Programs is added but also ~/Programs/sbt, ~/Programs/other_program, etc.? And if not, is it a good idea to make it recursive? I've tinkered with the Linux kernel before as part of a university class, I wonder if it's worth experimenting with.
Add something like this to ~/.bashrc or ~/.bash_profile:
for each in ~/Programs/*
do
PATH+=:"$each"
done
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
We have a number of machines with the Oracle JRE and JDK installed from RPM on our RHEL 5.x system (e.g. java-1.6.0-sun-devel-1.6.0.26-1jpp.1.el5.x86_64 and java-1.6.0-sun-1.6.0.26-1jpp.1.el5.x86_64 ). I mounted the JVM directory and compared them from Beyond Compare and found a consistent pattern of differences. In, say, the keytool on one machine there is a binary sequence that shows up in several locations in the file. In that same file in the same location on another machine, there is a different binary sequence. Each machine has it's own unique sequence in those locations. The unique binary sequence shows up in all the binary files that differ on a machine.
Is this some sort of watermark or signature? Is this common in ELF binaries installed from an RPM?
This just seemed weird to me, but it is probably just a curiosity. Thanks if you know what's up.
found a consistent pattern of differences
The RPM post-install script must be doing something; possibly embedding a watermark.
Is this common in ELF binaries installed from an RPM?
No.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I downloaded ChromePlus tarball and extracted it to my home directory. The extracted folder contains an executable that I can double-click to launch ChromePlus. So I assume I do not need to any extra things to install it.
I'm new to Linux. Where should I place ChromePlus directory? It's currently sitting on my home directory and it does not look neat. After googling, I thought about /bin/, /usr/bin, /usr/lib. Where is the best place?
I usually do so. I put the extracted directory to /usr/local and make a link to the binary in /usr/local/bin, so it looks something like:
/usr/local/bin/theapp -> /usr/local/Theapp/bin/theapp
If I care about upgrading Theapp and the extracted directory contains version then I also symlink "Theapp" to point to current version of it, e. g.:
/usr/local/Theapp -> /usr/local/Theapp-1.0.0
Since /usr/local may not be writable on some systems that you have access to, one's home directory is often the only place. For things like compiling the Linux kernel source code, using /usr/src, a path outside a home dir, is even discouraged.