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

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