Being dishonest, I could say what I have been told a while ago: "We don't support the upgrade of devel files" :)

What's the standard fix here? Obsolete/Provides of the versionned openmpi packages or something more subtle with the files?

OK, fine, but at least this should be written somewhere, and the uninstallation of *-devel should be suggested in the doc before upgrading.

I completely agree! That comment was not for you :)

I think we should support the upgrade of devel-files, that's why I am asking to more expert packagers the correct way to fix it!

That was incorrect Chris, we do support this (we just don't support co-installing 32-bit and 64-bit devel packages).

The reason this kind of conflict happens (and it doesn't just affect -devel's, but any package with subpackages) is because of a file being moved from one subpackage to another.  When you do that, you have to add, on the subpackage the file is moved *to* a Conflicts: package the file was moved *from* < the version-release when the move happened.

So in this case, the openmpi package itself would have a Conflicts: %{_lib}openmpi-devel (there should be a better variable name for that in the SPEC) < 4.0.1-1.

Thanks for the info.

We should have an automated way to spot this, or better, overcome this during upgrade!!

These kinds of move of a file happen all the time upstream, and they are impossible to track since the package at time "t" is always fine. So if upgrading mageia fails due to this, then, Houston, we have a problem!!!

Perhaps we could have a very big test pre-release that will install ALL the packages of Mageia N, and then, launch an upgrade.
We could disable some big packages (e.g 0ad-data) to speedup the process, and I bet this would reveal some hidden conflicts.

@David
That's a packaging issues from my side, these files have been matched by a "*" in both the devel and openmpi %files sections. I don't understand how I did not get a warning/error?

I have uploaded version 4.0.1-1.1 for mga 7 in updates_testing.

You can test if the offending files are now correctly packaged by installing the "lib(64)openmpi-devel" package and the "openmpi" package. Then, doing:

rpm -ql lib64openmpi-devel | grep .txt

should return:

/usr/share/openmpi/mpiCC-wrapper-data.txt
/usr/share/openmpi/mpic++-wrapper-data.txt
/usr/share/openmpi/mpicc-wrapper-data.txt
/usr/share/openmpi/mpicxx-wrapper-data.txt
/usr/share/openmpi/mpif77-wrapper-data.txt
/usr/share/openmpi/mpif90-wrapper-data.txt
/usr/share/openmpi/mpifort-wrapper-data.txt
/usr/share/openmpi/ortecc-wrapper-data.txt

And doing:

rpm -ql openmpi | grep .txt

should return a long list of *.txt files, but NOT the ones above!


Suggested advisory:
========================

Updated openmpi package to version 4.0.1-1.1 to fix double packaging issues preventing a proper upgrade from mga6 to mga7.


References:
========================
https://bugs.mageia.org/show_bug.cgi?id=26062

Updated packages in core/updates_testing:
========================
lib(64)openmpi40-4.0.1-1.1.mga7
lib(64)openmpi-devel-4.0.1-1.1.mga7
lib(64)openmpi-static-devel-4.0.1-1.1.mga7
openmpi-4.0.1-1.1.mga7


Source RPMs: 
openmpi-4.0.1-1.1.mga7.src.rpm

Assignee: eatdirt => qa-bugs
CC: (none) => eatdirt

Chris, actually the double packaging *does* result in a warning, but you never know if you don't look at the build logs.  Most packagers only look at the build logs when their packages fail to build, not when they build successfully.

Good to know. I think we should promote that to a build failure, in view of the consequences for distro upgrade!

Such warnings usually do not result in conflicts and failures.  You could argue that the build system should send an e-mail if there are warnings (if rpmbuild/iurt makes that possible to detect through return code), but it certainly should not be fatal.  As to this specific issue, it's not something that can be automatically detected.  Packagers just have to be careful to make sure to add in the proper Conflicts when moving files from one subpackage to another.

MGA7-64 Plasma on Lenovo B50
No installation issues, so the update is OK for its purpose.
Took inspiration for further testing from bug 2787.
$ mpicc --version
gcc (Mageia 8.3.1-0.20191101.1.mga7) 8.3.1 20191101
Copyright © 2018 Free Software Foundation, Inc.
etc....

$ mpirun --version
mpirun (Open MPI) 4.0.1
Report bugs to http://www.open-mpi.org/community/help/

$ mpif90 --version
GNU Fortran (Mageia 8.3.1-0.20191101.1.mga7) 8.3.1 20191101
Copyright © 2018 Free Software Foundation, Inc.
etc......

$ mpicc --help
Gebruik: gcc [opties] bestand...
Opties:
  -pass-exit-codes         Exit with highest error code from a phase.
  --help                   Display this information.
  --target-help            Display target specific command line options.
  --help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...].
etc....

Copied an example file from /usr/share/doc/lib64openmpi-devel/examples/ and compiled it.
$ mpicxx -o hello.out hello_cxx.cc 
$ ./hello.out 
Hello, world!  I am 0 of 1(Open MPI v4.0.1, package: Open MPI iurt@rabbit.mageia.org Distribution, ident: 4.0.1, repo rev: v4.0.1, Mar 26, 2019, 117)

Looks good enough for me.

CC: (none) => herman.viaene
Whiteboard: (none) => MGA7-64-OK

Validating. Advisory in Comment 8.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

@Chris
Thanks for the advisory in c8. There is no need to give this bug number as a 'Reference'; it gets added automatically.

Keywords: (none) => advisory

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2020-0030.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED