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.

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.

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@centos.org https://lists.centos.org/mailman/listinfo/centos-devel