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