Description of problem: java-openjdk-1.8.0.272.b02 package for x86_64 has a dependency to libvtk1-8.2.0.9.mga8.i386 which conflict with installed package lib64vtk1 Version-Release number of selected component (if applicable): cauldron 2020-08-19 How reproducible: try to update Steps to Reproduce: 1. 2. 3.
Please explain the circumstances giving rise to this bug. You mention 'update' in the title; is this something that happens doing an upgrade from Mageia 7 to 8 ? Or a routine update of a Cauldron/M8 system? If so, can you give some information about the update that gave rise to the conflict? The last one for java-1.8.0-openjdk ? Having looked at this, I find: - java-1.8.0-openjdk does not seem to require lib[64]vtk1: $ urpmq --requires java-1.8.0-openjdk | grep vtk1 $ $ urpmq --requires-recursive java-1.8.0-openjdk | grep vtk1 $ - lib64vtk1 does not seem to be required by java-1.8.0-openjdk: $ urpmq --whatrequires lib64vtk1 does not show it. As for libvtk1-8.2.0.9.mga8.i386, I cannot find it at all (but do not have any 32-bit repos enabled). It does not look right to have any reference to it on a 64-bit system. Await your feedback.
Source RPM: (none) => java-1.8.0-openjdk-1.8.0.272.b02-0.0.ea.3.mga8.src.rpmCC: (none) => lewyssmith
Probably due to the resync with Fedora. They have explicit Requires on libraries, using the SRPM name which is also the RPM name in Fedora (but not Mageia). We can just drop those explicit Requires as they are auto-generated.
Assignee: bugsquad => mageia
i don't see it : $ grep -r "vtk" SPECS/java-1.8.0-openjdk.spec $
Well I solve it but do not understand at all what happened! updating from mga-applet asked me to remove lib64vtk-devel (I answered yes) and proposed to update a list of packets. The one having problems was libvtk1-8.2.0.9.mga8.i386 conflicting with lib64vtk1 which is already installed on my system. Each times I selected java-openjdk-1.8.0 it also tried to install libvtk1-8.2.0.9.mga8.i386 and finally the transaction was canceled at the end. I've done it from the console: # urpme lib64vtk-devel # urpmi java-1.8.0-openjdk and everything is ok. Lewis and Nicolas are right, it was not a packet dependency trouble. So it was just a strange thing with mgaapplet. It looks also to me that the tagged list of packages is not always consistant with what the applet wants to install and that untagging an item is not always taken in account.
@DavidW: thanks for your comment. Leaving this with Nicolas.
CC: lewyssmith => (none)
Closing this. Strange behavior self-solved by user. mgaapplet has sometimes a strange behavior when selecting or deselecting updates in UI.
Resolution: (none) => WORKSFORMECC: (none) => ouaurelienStatus: NEW => RESOLVED