@lecris A PR implementing the above changes would be ideal.

I don't know a lot about MPI, but I do know this has been std. practice in Fedora/RHEL for over a decade (and people were actively using multiple MPI implementations on a single binary) ... so I'd want a bunch of MPI library/app maintainers input before just dropping this requirement.

For the second point I think there are ways to workaround that code without breaking anything, that could go upstream. For example the script is probably invoked with a fixed number of names (probably just cp2k and cp2k_shell) so it might be possible to look at prefixes.

Hi, sorry for not being active, I did not receive notifications.

so I'd want a bunch of MPI library/app maintainers input before just dropping this requirement.

Agreed, can someone ping relevant people? I think we can have a transition period where both variants are defined, but it would give deprecation warning

For example the script is probably invoked with a fixed number of names

The issue is that this is defined in the compiled executable itself.

@lecris A PR implementing the above changes would be ideal.

I will try to get back to this topic.

I have a design question, how can we convert something like:

for mpi in '' mpich %{?with_openmpi:openmpi}; do
  if [ -n "$mpi" ]; then
    module load mpi/${mpi}-%{_arch}
    cmake_mpi_args=(
      "-DCMAKE_INSTALL_PREFIX:PATH=${MPI_HOME}"
      "-DCMAKE_INSTALL_Fortran_MODULES:PATH=${MPI_FORTRAN_MOD_DIR}/cp2k"
      "-DCMAKE_INSTALL_LIBDIR:PATH=lib"
      "-DCP2K_CMAKE_SUFFIX:STRING=${MPI_SUFFIX}"
      "-DCP2K_DATA_DIR:PATH=%{_datadir}/cp2k/data"
      "-DCP2K_USE_MPI_F08:BOOL=ON"
    )
  else
    cmake_mpi_args=(
      "-DCP2K_USE_MPI:BOOL=OFF"
      "-DCMAKE_INSTALL_Fortran_MODULES:PATH=%{_fmoddir}/cp2k"
    )
  fi

Particularly the use of module load mpi/${mpi}-%{_arch} to a macro format. I am asking this becuase there seem to be some recommendations that are specific to each environment, e.g.

 export PRTE_MCA_rmaps_default_mapping_policy=:oversubscribe

These seem to impact the build and test time significantly

I think the only reasonable way would be to write it as Lua and define it as an RPM Lua-based macro. @gotmax23 has a fair bit of experience with RPM Lua macros, and may be able to help here.

I think I'm missing context here, but I can try my best to help if you explain in detail what you're trying to do. In general, I recommend not using Lua unless shell + macro syntax is significantly more difficult or impractical. Lua is less testable and less familiar to some in the packaging community, but yes, it can be quite powerful for certain usecases.

Context is that I have the following .spec file: https://github.com/LecrisUT/cp2k/blob/b8d40d7566de83ad92ab206c68ff417f7ebd5b86/tools/fedora/cp2k.spec#L155-L207
(similar to the one in the snippet above)

Insider I have a for loop over openmpi/mpich/serial with some if for some of the cases. Thing is using the provided macros like %_openmpi_load is much preferred, but I am not aware of a method that take the for variable and use it in the spec macro

A way to not having to if/else the %_openmpi_load would be great.

I do not understand the guidelines. Why would I care which mpi version of the executable I invoke?
Do I not always want the one of the currently loaded module?

It sounds to me like I should always type either
mpirun -n 72 binary_mpich or mpirun -n 72 binary_openmpi. And if I forgot which module is currently loaded I will get an error. What would be the point?

I am certainly in favor of changing that, if that is what the guidelines are requesting.

Also, I guess in general I do not want the serial version. As mentioned already, it may not work at all, and in general the mpi version should be mostly the same as the mpi one. And if for some reason (e.g. benchmarking) I want the serial version, I can always specify the full path.

Concerning setting PRTE_MCA_rmaps_default_mapping_policy, I think you can just always set them, mpich should not care about this one. At least this is what I do:
https://src.fedoraproject.org/rpms/bout++/blob/rawhide/f/bout++.spec#_522

I am certainly in favor of changing that, if that is what the guidelines are requesting.

Yes, that is the original purpose of the issue, and btw, the PR is at: https://pagure.io/packaging-committee/pull-request/1335

I basically think the original software's naming convention should be preserved. If they have different names for serial and parallel, so be it, if it's the same, all the more better. But we shouldn't enforce such suffix naming convention, especially since it can have so many unforeseen consequences.

I will split the topic of simplifying the spec file to a separate issue: https://pagure.io/packaging-committee/issue/1345

So this deserves consideration, but as mentioned elsewhere, FPC doesn't really have MPI experts. I think we could easily consider things which look sane, but what I'm concerned about is just pushing things into the guidelines that don't have support from the general community of MPI packagers or SCITECH SIG members. It's not really easy for us to determine how much support this has from those communities.

So yes, I think we're all for making things better for the packagers, assuming that the changes are things those packagers really want. I see what could be potentially three of those folks in this ticket ( @rathann , @davidsch and of course @lecris ) but what I don't know is whether those three are representative of the relevant communities.

Definitely scitech sig members should comment on this. @orion @rdieter @sagitter. Not sure who else to ping about this.

@tibbs FYI, I don't consider myself an MPI expert and I'm no longer active in the SciTech SIG.