... 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.u...@gmail.com otheus.shell...@uibk.ac.at
_______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
