On 26/01/17 23:08, Manuel Wolfshant wrote: > On 01/27/2017 01:00 AM, Anssi Johansson wrote: >> 26.1.2017, 22.35, lejeczek kirjoitti: >>> >>> >>> 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. >> >> ctdb-4.4.4-9.el7 was released with 7.3.1611 so it is in >> the "os" directory, whereas ctdb-4.4.4-12.el7_3 is in the >> "updates" directory. >> >> See, the problem is (with bind, as that's the package >> that I have installed, so easier to demonstrate -- >> downgrading from el7_3.1 to el7_3): >> >> Processing Dependency: bind-libs = 32:9.9.4-38.el7_3 for >> package: 32:bind-9.9.4-38.el7_3.x86_64 >> >> The old package wants to have "bind-libs = >> 32:9.9.4-38.el7_3". Now when you run "yum provides >> 'bind-libs = 32:9.9.4-38.el7_3'" you will get two entries >> -- the i686 version and the x86_64 version. Yum chooses >> the first one, and that decision ends up in tears. If you >> list each package and its dependencies on the "yum >> downgrade" command line, it will apparently help yum >> enough to make the correct decisions. >> >> If you run "rpm -q bind-libs --provides" you will see: >> bind-libs = 32:9.9.4-38.el7_3.1 >> bind-libs(x86-64) = 32:9.9.4-38.el7_3.1 >> (and some others) >> >> Compare this with "rpm -q bind --requires | grep libs", >> which outputs >> bind-libs = 32:9.9.4-38.el7_3.1 >> >> Now if bind was specified to require "bind-libs(x86-64) = >> 32:9.9.4-38.el7_3.1" instead of "bind-libs = >> 32:9.9.4-38.el7_3.1", "yum downgrade" would work >> smoothly. If you read the Bugzilla link I posted above, >> the fix for the similar java problem was to change the >> package spec to include the architecture in the requirement. >> >> Not sure if/when/how the Red Hat guys are going to make >> changes to the other packages, or if they will change yum >> so that such changes to package specs would not be >> necessary. >> >> It is also possible that there might be some obscure >> config entry in yum which controls this, but I was unable >> to find one. > if I am not mistaken multilib_policy=best should do it. > but AFAIK this is the default value so I am as puzzled as > Lejeczek is well, would it mean that dnf shares code/logic or.. it's ... I don't know, that thing is that - it seems dnf does the same. Can you see it too? > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel