I have foo-1.1 and foo-devel-1.1 both installed. Now I update my repo with foo-1.2 and foo-devel-1.2. After yum clean metadata, I simply type yum update, no problem. I get both foo-1.2 and foo-devel-1.2 reported as ready to update.
However, if I type yum update foo-devel the related foo dependency is not reported as ready to update. Is this correct behavior? How do I get the behavior I'm expecting? Which is that all dependencies resolve and update when a package name is specified as an argument to yum update.
$rpm -q yum
yum-3.2.29-43.el6_5.noarch
Thanks for any info!
-Fin
When updating all packages
yum update will update any packages that have a newer version available, and take care of dependencies.
From the manual page man yum:
While updating packages, yum will ensure that all dependencies are satisfied.
One thing to bear in mind is that while a package may have an update available, that does not mean that a dependency of that package has been updated too - they are after all seperate packages.
When updating a specific package
From the manual: If one or more packages or package globs are specified, Yum will only update the listed packages.
This seems to imply that if foo-devel requires foo, and you specify to update only foo-devel, then yum won't update foo to a newer version (unless foo-devel specifically requires the newer version).
Related
In my CMakeLists.txt, I have the following:
set(CPACK_RPM_PACKAGE_REQUIRES "boost148, intel-daal-core-2018.1-163, \
intel-mkl-core-2018.1-163")
My problem is that when I do a yum install,the intel-mkl-core-2018.1-163 library gets installed, but when I do yum update on a machine that did not have intel-mkl-core - it does not get installed.
I also tried yum upgrade, with the same results.
The above does not seem to be the correct behaviour. Any suggestions on how to debug this issue?
(OS: CentOS/RedHat 7)
yum update means: update every currently installed package. If intel-mkl-core was not installed before, it won't be updated...
yum install means: install (or update) this package even if it was not installed before.
I have packages Foo-2.0.rpm and Foo-2.3.rpm. The former is normally distributed by the Linux distro but old. Foo-2.3 is the latest version, and the rpm I am making. I am writing the .spec file, and for now, keep it in my own repo.
I thought--and I thought I even did--that I could replace Foo-2.3 with Foo-2.0 (downgrade to the stable version) by doing the following:
yum-config-manager --disable myrepo
yum --update Foo
Provided that Foo-2.3 was installed, the expected outcome is to have Foo-2.0 in place of Foo-2.3.
However, now, it gives me the following message only:
# yum update Foo
No packages marked for update
"yum downgrade Foo" seems a working command.
Why "yum update" does not work as I expected? Is it because of my spec file? Or is it just something that is not working?
In the .spec file of Foo, Foo "Provides: Foo-2.3," and "Conflicts: Foo <= 2.1." I have lost a few the spec files in development. Although I think disabling the repo and "yum update" downgraded Foo, my memory might be wrong.
yum upgrade always went up. When in the repo is a higher version, then upgrade. If there is older, just do nothing. It always acted this way. Even rpm itself behave this way. But for rpm you can force it to downgrade with upgrade with rpm -Uvh --force Foo-2.0.rpm. For yum there is no way. You have to use downgrade command.
And BTW in your spec file should be:
Provides: Foo-2.3
Obsoletes: Foo <= 2.1
But this is usually needed when you rename the package. Which I believe is not your case.
Couldn't find an answer anywhere so I will try here.
Is there a way to tell yum, while running yum update, to update a specific package as the last one?
I am not talking about requires / dependencies, It just needs to be updated after all other packages on the system.
In a nutshell, I manage local repositories in my environment and this particular rpm holds the version for each repository, so by updating it as last I can label the client with that particular version.
You can run two yum commands. First one excluding the .rpm that you don't want to be updated and second, running your usual update.
$ yum --exclude="foo*.rpm" update
If foo*.rpm comes from a particular repository, then during the update, you can disable it using its name. Name of a repository can be found by looking into /etc/yum.repos.d/*.repo file or using the command
$ yum repolist
Then disable the repo and update. Note, this will disable update of all packages coming from this repo.
$ yum --disablerepo="nameOfRepo" update
Finally, run your usual update
$ yum update
On last Friday morning, I tried a "yum update" on my CentOS laptop, and it reported this:
Loaded plugins: fastestmirror, langpacks, verify
Loading mirror speeds from cached hostfile
* base: repo1.dal.innoscale.net
* epel: fedora-epel.mirror.lstn.net
* extras: mirror.unl.edu
* nux-dextop: mirror.li.nux.ro
* rpmfusion-free-updates: mirror.us.leaseweb.net
* updates: mirror.spro.net
Resolving Dependencies
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.16.2.3-13.el7_1 will be updated
---> Package nss-softokn-freebl.i686 0:3.16.2.3-14.2.el7_2 will be an update
---> Package python-ecdsa.noarch 0:0.11-3.el7.centos will be obsoleted
---> Package python2-ecdsa.noarch 0:0.13-4.el7 will be obsoleting
---> Package tzdata.noarch 0:2016c-1.el7 will be updated
---> Package tzdata.noarch 0:2016d-1.el7 will be an update
---> Package tzdata-java.noarch 0:2016c-1.el7 will be updated
---> Package tzdata-java.noarch 0:2016d-1.el7 will be an update
--> Finished Dependency Resolution
Error: Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:
1. You have an upgrade for nss-softokn-freebl which is missing some
dependency that another package requires. Yum is trying to
solve this by installing an older version of nss-softokn-freebl of the
different architecture. If you exclude the bad architecture
yum will tell you what the root cause is (which package
requires what). You can try redoing the upgrade with
--exclude nss-softokn-freebl.otherarch ... this should give you an error
message showing the root cause of the problem.
2. You have multiple architectures of nss-softokn-freebl installed, but
yum can only see an upgrade for one of those architectures.
If you don't want/need both architectures anymore then you
can remove the one with the missing update and everything
will work.
3. You have duplicate versions of nss-softokn-freebl installed already.
You can use "yum check" to get yum show these errors.
...you can also use --setopt=protected_multilib=false to remove
this checking, however this is almost never the correct thing to
do as something else is very likely to go wrong (often causing
much more problems).
Protected multilib versions: nss-softokn-freebl-3.16.2.3-14.2.el7_2.i686 != nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64
I asked about this on #centos, and someone gave me some exploratory advice, but no real solution.
I experienced the very same issue on a Fedora 20 system (run in a docker container) when trying to install i686 development libraries. Reason were two not matching versions for x86_64 and i686, respectively.
Protected multilib versions: nss-softokn-freebl-3.19.1-1.0.fc20.i686 != nss-softokn-freebl-3.19.2-1.0.fc20.x86_64
For me it helped to call
yum distribution-synchronization
That automatically downgraded the x86_64 version. After that
I could install with
yum install nss-softokn-freebl.i686
and
yum list installed | grep nss-softokn-freebl
showed now:
nss-softokn-freebl.i686 3.19.1-1.0.fc20 #updates
nss-softokn-freebl.x86_64 3.19.1-1.0.fc20 #updates
Problem solved.
I have tried to install mod_security, but it has the error, so I tried aptitude:
apt-get install libapache-mod-security
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libapache-mod-security : Depends: libapache2-modsecurity but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root#srv16540:~# aptitude install libapache2-modsecurity
The following NEW packages will be installed:
apache2.2-common{ab} libapache2-modsecurity modsecurity-crs{a}
0 packages upgraded, 3 newly installed, 0 to remove and 10 not upgraded.
Need to get 660 kB of archives. After unpacking 2,861 kB will be used.
The following packages have unmet dependencies:
apache2 : Conflicts: apache2.2-common but 2.2.22-1ubuntu1.4 is to be installed.
apache2.2-common : Depends: apache2.2-bin (= 2.2.22-1ubuntu1.4) but 2.4.6-2~precise+1 is installed.
apache2-bin : Conflicts: apache2.2-common but 2.2.22-1ubuntu1.4 is to be installed.
apache2-data : Conflicts: apache2.2-common but 2.2.22-1ubuntu1.4 is to be installed.
The following actions will resolve these dependencies:
**Keep the following packages at their current version:**
1) apache2.2-common [Not Installed]
2) libapache2-modsecurity [Not Installed]
3) modsecurity-crs [Not Installed]
Accept this solution? [Y/n/q/?] q
Abandoning all efforts to resolve these dependencies.
I do now know what Keep the following packages at their current version means.
I want to know what does happen if I press yes. Does it replace my current apache2? Do I need to back up before doing this?
ANSWERS
I do now know what Keep the following packages at their current version mean
aptitude is trying to resolve the dependencies and possible conflicts to satisfy your installation request. It then proposes a solution. In your particular case the first solution it finds is to keep everything as it actually is, that's what keep at their current version + [Not installed] means.
I want to know what does happen if I press yes , does it replace my current apache2 ?
No, that solution will basically do nothing.
Do I need back up before ?
As boring as it sounds, backups are a good strategy to save time in the long run. If you're messing with important data then it should be even more important for you.
CONTEXT
I've seen other scenarios make aptitute propose solutions with combinations like these:
Remove the following packages
Keep the following packages at their current version
Leave the following dependencies unresolved
The following packages have been kept back
The following packages will be upgraded
The following packages were automatically installed and are no longer required
The following extra packages will be installed
Suggested packages
The following packages will be REMOVED
(and probably others)
In your case if instead of accepting the solution (or quitting), you reject it by pressing n, then aptitude will try to figure out another scenario that could be useful and propose it to you again. You can iterate through the solutions doing that and if any of them satisfies you then you can accept it.
SOLUTION (?)
As far as I can see by your output:
apache2.2-common : Depends: apache2.2-bin (= 2.2.22-1ubuntu1.4) but 2.4.6-2~precise+1 is installed.
Your problem is that you have apache2-2.4.6-2~precise+1 installed which isn't available from standard Ubuntu precise repositories (most probably installed from this PPA), and you're requesting a package which conflicts with that other one.
I'd take a look at the answers on how to remove PPAs and after you have removed that source I'd reinstall apache 2.2 from the standard repos with this command:
sudo aptitude install apache2
That's exactly what it did for me:
$ sudo apt-get remove apache2-bin
$ sudo apt-get autoremove
$ sudo apt-get install apache2
Open synaptic manager and search for apache2.2-bin. Mark it for removal. Then
sudo apt-get install apache2
Just remove all the content of /var/lib/apt/lists directory:
sudo rm -rf /var/lib/apt/lists/*
then run:
sudo apt-get update