Tag Info

New answers tagged

0

You can use the command line tool repotrack to download everything required by a given package. It purely looks at the repos so will download everything, regardless if it's already installed or not. repotrack - track a package and its dependencies and download them Example $ repotrack -a x86_64 -p . vim-enhanced Downloading ...


0

With: rpm -qlp package.rpm command you can list files inside a rpm file. Executables probably will be in some bin folder. So: rpm -qlp package.rpm | grep bin can work too.


2

As several others already have stated, look for "/bin" in the packages file list. Here's Gentoo $ equery f firefox | grep bin equery is part of the package gentoolkit.


6

The same for Debian; for an installed package, dpkg -L <packagename> | grep -F /bin/ dpkg -L lists out the package's contents (basically prints /var/lib/dpkg/info/<packagename>.list) and the grep picks out any file paths containing /bin/. For a deb file which you have not yet installed, dpkg-deb -c path/to/filename.deb | grep -F /bin/


14

I usually list out the contents of the RPM and filter it using /bin/. The files in that directory are executable. $ rpm -ql ImageMagick | grep /bin/ /usr/bin/animate /usr/bin/compare /usr/bin/composite /usr/bin/conjure /usr/bin/convert /usr/bin/display /usr/bin/identify /usr/bin/import /usr/bin/mogrify /usr/bin/montage /usr/bin/stream


-1

The following combination of things worked for me: delete the actual files in /etc/yum.repos.d yum clean all rpm -qa | grep epel (still shows) yum remove epel* yum clean all This finally cleaned it out.


0

Finally managed to fix this problem. Wasn't has difficult as I thought ! The guy at fedora was right. sideburns said, responding to the question (first link on my question): From what you've written, you installed both packages from a third-party repo instead of using the ones from the standard Fedora repo. If so, remove them, remove the repo they came ...


0

Can you make sure you have no epel-release packages left by listing all packages and grepping epel? rpm -qa | grep epel If there is no package in that list, you can also force install the epel-release package by running: rpm -ivh --force epel-release-6-8.noarch.rpm


0

I ran into the same problem and finally i found a solution: Remove all vmware packages that are installed via yum until yum list installed | grep vmware shows nothing: yum list installed | grep vmware yum remove vmware-tools-guestlib.x86_64 yum remove vmware-... yum remove kmod-vmware-... ... Remove files and folders found by "locate vmware". For me it ...


0

download the rpm from this link rpm -Uvh openssl-1.0.1e-16.el6_5.14.x86_64.rpm rpm -Uvh https://mirror.webtatic.com/yum/el6/latest.rpm yum install php54w


2

Is my understanding of the above commands correct ? Yes What does the local repo mean ? Is it a directory that contains all the packages If you are configuring your own yum repository (or your system admin. in your lab) then it may refer as local yum repository. It may be on local system or on a private network. Ref: How to ...


0

This is similar to Daniel's answer but, I used the following command: service network restart ifup e* This automatically boots up the named adapter (enp0s3 in my case, since ifup eth0 didn't work)


-1

Use this: # sudo yum clean all # sudo yum update


0

I have hit this same problem on CentOS 6.x for PGDG installs from Postgres 9.0 - 9.3. Here was how we resolved it: First I downloaded and installed the Postgres version I was after: yum install http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/pgdg-redhat92-9.2-7.noarch.rpm When trying to install the postgresql92 packages, I hit the same error: Error: ...


0

For me, looking into the newer atomic-release package rpm it seems that a new GPG key was added and is in use so if you didn't upgrade for a while you'll likely get this issue. To fix you need to manually download and import the key and update the repo config: wget https://www.atomicorp.com/RPM-GPG-KEY.atomicorp.txt mv RPM-GPG-KEY.atomicorp.txt ...


1

I took larsks answer one step farther. $ package-cleanup --leaves | xargs -l1 yum -y remove This grabs all of the dependencies that can be removed without affecting anything else and then removes them. Better then going through one by one. And if you want a little more control get rid of the "-y" then yum will ask you if you want to remove the package ...


0

run sudo yum clean all then run sudo yum update and the system should now have all updates and software new to the server.


0

Dead repo. That's a non-standard repo that someone used to get some of your packages. I'd determine what's coming from that repo and disable it in the /etc/yum.repo.d/* .repo files for it. You can determine which packages came from this repo if you know its shortname. Example Say this was in the .repo file associated with that repo. [fedora] name=Fedora ...


2

The packages perl(Net::Telnet) are what are called virtual packages. They exist only in name and are essentially an "alias" for the real package whose name is really perl-Net-Telnet. These packages come into existence through their definition within the .spec file as provides or requires. You can see some here in this package, perl-Net-HTTP: $ more ...


1

It's been my experience that no, createrepo cannot recursively walk a directory tree. You therefore have to flatten your repo's directory structure. I usually use this type of looping construct in my repo building script. destdir="/path/to/my/yum-repos/Fedora/14" for arch in i386 x86_64 noarch; do printf "\n\n==== creating repo: %-50s [%-s]\n" $destdir ...


1

No, updating a disabled service with yum should not re-enable it. I suspect however that you never actually stopped the service - doing systemctl disable just stops it starting automatically the next time you boot. If the service is already running then it won't stop it - you need to do systemctl stop for that. So if you just disabled it, and you haven't ...


2

Try using YUM's shell transactions: # yum shell > > remove <package> > repo disable <repo ID of not required package> > install <package> > run


4

Python is required by many of the Linux distributions. Many system utilities the distro providers combine (both GUI based and not), are programmed in Python. The version of python the system utilities are programmed in I will call the "main" python. For Ubuntu 12.04 e.g. this is 2.7.3, the version that you get when invoking python on a freshly installed ...


3

Technically, i686 is actually a 32-bit instruction set (part of the x86 family line), while x86_64 is a 64-bit instruction set (also referred to as amd64). From the sound of it, you have a 64-bit machine that has 32-bit libraries for backwards compatibility. That should be totally fine.


0

If you dig i686 in Wikipedia, Wikipedia will tell you clues that the i686 microarchitecture is considered as a x86 extension. In general all x86 architectures are considered similar, and the x86_64 (or maybe amd64) architecture is considered in another microarchitectures group.


0

My solution was similar to @slm's but I used SOCKS instead because it is simpler and required no proxy installation on the server or client. Run all commands on the computer with restricted acccess. in yum.conf set the proxy as follows proxy=socks5h://localhost:1080 from a terminal type ssh -D 1080 YOUR_USER@YOUR_SERVER_WITH_FULL_WEB_ACCESS press ...


0

Unfortunately, Fedora 20 doesn't have the Python 3 version of this library, but Fedora 21 has it (see RPM SPEC commit). As a side note, while the Fedora Packages web page for python3-pandas might lead you think that it's available for Fedora 20 and 19, it's not. I've reported a bug about this.


0

Add this line to /etc/yum.conf and make sure to use the expected protocol (not http): ... proxy=socks5h://localhost:1080 ...


0

I'm answering from the perspecting of apt, but I believe this is all the same for yum. Updates are fetched over HTTP or FTP, not HTTPS. The idea is that the payload doesn't need to be encrypted, only unmodified, so "sufficient" security is achieved by a PGP signature on the index. But the replay attack is a problem! In order to be scalable, updates and ...


1

You should be able to proxy YUM's traffic over the SSH connection like so: add to the /etc/yum.conf on the protected server: proxy=http://127.0.0.1:8080 from the server with normal inbound/outbound ssh access: $ ssh -R 8080:ssh.server:8080 user@protected.server On the server where you want to run YUM commands: $ yum update References Port Forward ...


0

The major differences between YUM and RPM are that yum knows how to resolve dependencies and can source these additional packages when doing its work. Though rpm can alert you to these dependencies, it is unable to source additional packages. As to installing vs. upgrading. Both tools can perform an install, and RPM will even allow you to install multiple ...


1

This is pretty pervasive information on the internet, assuming you know what to search for. You need to setup a local YUM repository using server1. Details are described here: Setup Local Yum Repository on CentOS / RHEL / Scientific Linux 6.4 The general approach is that you'll need either an FTP server or HTTP server which can access the directory where ...


2

The only way I found so far is vimdiff:


0

The easiest way to fix your problem is to manually install the package (which yum has downloaded into /var/cache/yum/... somewhere) using rpm -Uvh --replacefiles However you likely have some more "fumbling attempts" ;-) to clean up. Try doing rpm -qa --last | more to see recent activity. You also should check for duplicated installations.


1

If the packages are already installed, yes you have to erase and reinstall using --relocate. The --relocate operates only during installation (though there is no important reason that the relocated paths could not be changed after an install, just noone has bothered, its quite easy to erase and reinstall).


0

So you have unsatisfied dependencies that you need to stub out. Make a dummy package that supplies the missing Provides: is the general approach. (aside) RPM5 (this isn't you) also permits Requires: to be stubbed out using a configuration file /etc/rpm/sysinfo/Providename.



Top 50 recent answers are included