Description of problem: I tried to install openfoam-v2006 downloaded from openfoam.com. It need lib64vtk-devel to compile. lib64vtk-devel has lib64vtk-static-devel and python3-vtk as dependencies. rpmdrake can't install python3-vtk package as a lot of files from the package conflict with the same files from paraview package. Version-Release number of selected component (if applicable): python3-vtk-8.2.0-10 (x86_64) paraview-5.8.0-7 (x84_64) How reproducible: Steps to Reproduce: 1.start rpmdrake and install paraview-5.8.0-7.mga8 (x86_64) 2.install lib64vtk-devel (x86_64) 3. I manage to install it manually by using: urpmi --replacefiles lib64vtk-devel And now everything is ok. So the workaround is easy but packages could maybe be corrected to work out of the box.
Thank you for pointing this out. > rpmdrake can't install python3-vtk package as a lot of files from the > package conflict with the same files from paraview package. $ sudo urpmi paraview ... $ sudo urpmi --test lib64vtk-devel file /usr/lib64/python3.8/site-packages/__pycache__/vtk.cpython-38.opt-1.pyc from install of python3-vtk-8.2.0-10.mga8.x86_64 conflicts with file from package paraview-5.8.0-7.mga8.x86_64 ... x 84 file /usr/lib64/python3.8/site-packages/vtkmodules/wx/__pycache__/wxVTKRenderWindowInteractor.cpython-38.pyc from install of python3-vtk-8.2.0-10.mga8.x86_64 conflicts with file from package paraview-5.8.0-7.mga8.x86_64 Probing the two example conflicts above: $ urpmf /usr/lib64/python3.8/site-packages/__pycache__/vtk.cpython-38.opt-1.pyc paraview: /usr/lib64/python3.8/site-packages/__pycache__/vtk.cpython-38.opt-1.pyc python3-vtk:/usr/lib64/python3.8/site-packages/__pycache__/vtk.cpython-38.opt-1.pyc $ urpmf /usr/lib64/python3.8/site-packages/vtkmodules/wx/__pycache__/wxVTKRenderWindowInteractor.cpython-38.pyc paraview: /usr/lib64/python3.8/site-packages/vtkmodules/wx/__pycache__/wxVTKRenderWindowInteractor.cpython-38.pyc python3-vtk:/usr/lib64/python3.8/site-packages/vtkmodules/wx/__pycache__/wxVTKRenderWindowInteractor.cpython-38.pyc So unsure where the responsibility lies. Assigning this globally, CC'ing the 2 packagers who have had recent affair with the SRPMs, plus DavidG who is shown for python3-vtk.
Source RPM: (none) => vtk-8.2.0-10.mga8.src.rpm, paraview-5.8.0-7.mga8.src.rpmAssignee: bugsquad => pkg-bugsCC: (none) => eatdirt, geiger.david68210, joequant
Yes, I suspect this comes from that fact that our paraview has a built in version of vtk. We could add a conflict between the 2 packages, but, out of curiosity, you were needing vtk-devel or paraview-devel, or both? (if both, please explain, that may prevent us to set a conflict). Thanks.
Hello Chris, I don't need paraview-devel but I need paraview as it's the tools to visualize openfoam's calculation results. And that's the package which conflict with lib64vtk-devel which is needed to compile openfoam from openfoam.com (openfoam's forks are on sites openfoam.com and openfoam.org. Mageia supply only openfoam from openfoam.org). I'm pretty sure that lib64vtk-devel is also needed to compile the last FreeCAD from sources and I do that from time to time to follow FreeCAD developing progress. So yes I need both paraview and lib64vtk-devel. paraview comes with some third party dependencies but when they are already supplied by mageia it looks to me they shoudn't be included as files in paraview's package but just listed as dependencies.
Taking a look at the packages.
CC: (none) => joequant
Submitted 5.8.1 to build. Also I'd like to split out openmpi/mpich/non-mpi packages. Would like to know how this affects you.
Well Joseph, I often use paraview directly on my openfoam cases and don't take advantages of parallelism for visualisation. More rarely I use openmpi to run pvserver on more processors of a node without visualization. In this case I use paraview as a client of pvserver from my visualization workstation. Never used mpich but as both mpich and openmpi are avalaible I can imagine some people use it. I've checked in cmake-gui options needed to compile paraview and there are only generic mpi options so that I think it doesn't care whether this in openmpi or mpich implementation. When paraview is used for visualizing openfoam cases and as mpi is absolutely necessary to accelerate openfoam's calculation, there is no cost of compiling paraview with mpi support. Anyway even if it's not for visualizing openfoam cases I'm not sure there would be an interest to compile paraview without mpi support. When it's compiled in, you can use it or not so I think it's better to include it.
Okay. If the current setup works for you, I'll keep it rather than fiddle with it. Let me know if you run into problems with any of the packages. I'm very happy to hear that someone is using the "monster" packages.
Well done Joseph, you managed to compile paraview against our vtk!? Good Job! (TM)
For MPI, it works, so, please, let it in. In addition, that's the power of paraview!
Closing as old
Resolution: (none) => OLDStatus: NEW => RESOLVED