We RHEL/CentOS users need a critical fix for yum: broken update-to

[otheus uibk]

... and we do not nor cannot wait for DNF to become yet another stalled
project slated for incorporation in RHEL15 or whatever. No offense to
team Šilhan, but forking and re-branding a well-established project is
simply dumb, wasteful, and harmful. Just make it "yum 4.0", while providing
a mostly or completely backward-compatible CLI and change the insides.
Don't pull another systemd, please. Now to the topic at hand:

The fundamental problem with "yum update" or "yum install" for that matter
is that even if the user specifies a version, fully specified, yum can and
will upgrade to the *latest* version available instead of the target
version, if at least the following condition applies: the target package
provides a capability that other packages require, and those other packages
require a newer version.

To try to illustrate this, let's say I want to upgrade Alpha from version
1.0 to version 1.1. I do NOT want version 2, because version 2 broke
things.  Package Alpha provides Alpha(x86-64) which is used by Alpha-server
and Alpha-libs. What *should* happen, is that yum verifies that version 1.1
exists, and that the provided capabilities meet the requirements of
installed packages. Alternatively, if they don't, then Alpha-server must be
upgraded to the lowest version that still allows Alpha version 1.1 to be
installed. If that cannot happen, the install fails for a dependency
problem.

Here's the real example: in the real world, we upgrade databases very
conservatively. I can probably go from postgresql93-9.3.1 to 9.3.5, but
after that, I will need to schedule downtime and make other changes. So I
don't want to go past 9.3.5.  If I use a tool such as puppet to manage my
environment, I can only specify the target version for each package, and
puppet will try to update each package singularly. Inevitably, I get 9.3.15
(or whatever is latest). (I don't get 9.6.2, because luckily, the package
basename includes the major release numbers, presumably for this very
reason, that yum updates are broken).

Also note: postgresql95 requires postgresql95-libs, so I instead try to
update the -libs package first. If I try to do "yum update-to
postgresql95-libs-9.5.3-2PGDG.rhel7" something like this happens in the
debug output:

Resolving Dependencies
--> Running transaction check
---> Package postgresql95-libs.x86_64 0:9.5.3-1PGDG.rhel7 will be updated
Checking deps for postgresql95-libs.x86_64 0:9.5.3-1PGDG.rhel7 - ud
postgresql95-9.5.3-1PGDG.rhel7.x86_64 requires: postgresql95-libs(x86-64) =
9.5.3-1PGDG.rhel7



stop right there. So what if postgresql95 requires postgresql95-libs? IT
SHOULD NOT MATTER.

--> Processing Dependency: postgresql95-libs(x86-64) = 9.5.3-1PGDG.rhel7
for package: postgresql95-9.5.3-1PGDG.rhel7.x86_64


NO! That's not a dependency! This is what the target package provides.


Needed Require is not a package name. Looking up: postgresql95-libs(x86-64)
= 9.5.3-1PGDG.rhel7
Potential Provider: postgresql95-libs.x86_64 0:9.5.3-1PGDG.rhel7

Mode is ud for provider of postgresql95-libs(x86-64) = 9.5.3-1PGDG.rhel7:
postgresql95-libs.x86_64 0:9.5.3-1PGDG.rhel7


duh.

Mode for pkg providing postgresql95-libs(x86-64) = 9.5.3-1PGDG.rhel7: ud
Trying to update postgresql95-9.5.3-1PGDG.rhel7.x86_64 to resolve dep


That's WRONG. There is no reason yet to make this determination because so
far, the target package has not been selected and inspected to see what
depends on it.

Eventually we get here:

---> Package postgresql95-libs.x86_64 0:9.5.3-2PGDG.rhel7 will be an update
Checking deps for postgresql95-libs.x86_64 0:9.5.3-2PGDG.rhel7 - u

which looks OK. Then we get to this...

--> Running transaction check
---> Package postgresql95.x86_64 0:9.5.3-1PGDG.rhel7 will be updated
Checking deps for postgresql95.x86_64 0:9.5.3-1PGDG.rhel7 - ud
---> Package postgresql95.x86_64 0:9.5.4-2PGDG.rhel7 will be an update
Checking deps for postgresql95.x86_64 0:9.5.4-2PGDG.rhel7 - u

What?!?! Wait!!!  How did we get from 9.5.3-1 to 9.5.4-2 ?? Debug level 9
doesn't offer insight. All I can guess is that the faux-dependency
triggered an attempt to update the dependency to the latest version.

And once it upgraded to the latest version, it in turn required a version
newer than what the user requested.

In the worst case, yum should *fail*. However, at least with 'update-to',
it should not try to update these dependencies of a capability. It should
only update packages according to the versions required by the required
packages.


-- 
Otheus
otheus.uibk at gmail.com
otheus.shelling at uibk.ac.at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.baseurl.org/pipermail/yum-devel/attachments/20161025/4a904ced/attachment.html>