[CentOS-devel] weird (non-functional) downgrade
lejeczek
peljasz at yahoo.co.uk
Fri Jan 27 11:20:43 UTC 2017
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
More information about the CentOS-devel
mailing list