On 26/01/17 20:16, Anssi Johansson wrote: > 26.1.2017, 21.45, lejeczek kirjoitti: >> >> >> On 26/01/17 17:46, Anssi Johansson wrote: >>> 26.1.2017, 19.18, lejeczek kirjoitti: >>>> dear devel >>>> >>>> is this true that every rpm downgrade goes kind of a >>>> ... "haywire" ? >>>> >>>> I've tried a few and... >>>> >>>> ~]$ yum downgrade ctdb >>>> --> Running transaction check >>>> ---> Package ctdb.x86_64 0:4.4.4-9.el7 will be a downgrade >>>> --> Processing Dependency: samba-client-libs = >>>> 4.4.4-9.el7 for package: >>>> ctdb-4.4.4-9.el7.x86_64 >>>> ---> Package ctdb.x86_64 0:4.4.4-12.el7_3 will be erased >>>> --> Running transaction check >>>> ---> Package samba-client-libs.i686 0:4.4.4-9.el7 will >>>> be installed >>>> <= ????? >>>> >>>> ~]$ yum downgrade bind >>>> Resolving Dependencies >>>> --> Running transaction check >>>> ---> Package bind.x86_64 32:9.9.4-38.el7_3 will be a >>>> downgrade >>>> --> Processing Dependency: bind-libs = >>>> 32:9.9.4-38.el7_3 for package: >>>> 32:bind-9.9.4-38.el7_3.x86_64 >>>> ---> Package bind.x86_64 32:9.9.4-38.el7_3.1 will be >>>> erased >>>> --> Running transaction check >>>> ---> Package bind.x86_64 32:9.9.4-38.el7_3.1 will be >>>> erased >>>> ---> Package bind-libs.i686 32:9.9.4-38.el7_3 will be >>>> installed <= >>>> ???? >>>> >>>> etc. >>>> and system has no signle 686 rpm. Some kind of a curse >>>> my boxes suffer >>>> from? :) >>> >>> It looks like resolving the dependencies is the problem. >>> If you tried >>> downgrading bind with a "yum downgrade bind bind-libs >>> bind-license >>> bind-utils bind-chroot bind-libs-lite", it would work. >> >> but something is plain wrong there, is it not? And it is >> not bind. >> Try another one, java: >> >> --> Running transaction check >> ---> Package java-1.8.0-openjdk.x86_64 >> 1:1.8.0.111-2.b15.el7_3 will be a >> downgrade >> --> Processing Dependency: java-1.8.0-openjdk-headless = >> 1:1.8.0.111-2.b15.el7_3 for package: >> 1:java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64 >> ---> Package java-1.8.0-openjdk.x86_64 >> 1:1.8.0.121-0.b13.el7_3 will be >> erased >> --> Finished Dependency Resolution >> Error: Package: >> 1:java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64 (updates) >> Requires: java-1.8.0-openjdk-headless = >> 1:1.8.0.111-2.b15.el7_3 >> Installed: >> 1:java-1.8.0-openjdk-headless-1.8.0.121-0.b13.el7_3.x86_64 >> (@updates) >> java-1.8.0-openjdk-headless = >> 1:1.8.0.121-0.b13.el7_3 >> Available: >> 1:java-1.8.0-openjdk-headless-1.8.0.102-4.b14.el7.i686 >> (base) <= ??? >> why does this i686 arch try to force its way in? Each time. >> >> It smells like something fundamental. >> Could it be that yum repos are somehow broken. >> Being a long time ex-user of Scientific I remember I >> never had seen >> anything similar. Downgrading samba after a buggy update >> saved me a few >> times. >> Would be really good to know that we Centosians can rely >> on yum/dnf >> downgrade. > > I did not say that the behaviour was OK, I only provided a > workaround. In the java case, you would need to run "yum > downgrade java-1.8.0-openjdk java-1.8.0-openjdk-headless" > to downgrade java. Apparently yum can't pick the correct > architecture in this particular case. The repositories are > OK. The problem lies in how yum interprets the > requirements of each package, and what the packages provide. > > https://bugzilla.redhat.com/show_bug.cgi?id=1388520 is > related, and apparently in this particular case they will > adjust the java packages to add the matching architecture > requirement. > _______________________________ could be that some bits actually are missing in repo? If for example - yum downgrade ctdb - ought to work, then ... a version ctdb-4.4.4-12.el7_3.x86_64(current) would go back to ctdb-4.4.4-9.el7.x86_64(as the rest of samba suite) which I had just a few days ago, but... I'm looking at repo and .. I fail to find it. > ________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel