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

Fri Jan 27 11:20:43 UTC 2017
lejeczek <peljasz at yahoo.co.uk>


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