[CentOS-devel] weird (non-functional) downgrade

Thu Jan 26 23:00:19 UTC 2017

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.