Quoting "Milos Jakubicek" xjakub@fi.muni.cz:

On 26.7.2009 14:38, Jussi Lehtola wrote:

...

Hello again,

I have updated the MPI draft at https://fedoraproject.org/wiki/PackagingDrafts/MPI to take into account the comments that araised in discussion on the list.

Looks great, just three minor comments:

1. Shouldn't the suffix for OpenMPI be just "openmpi" instead of

"mpi"? It would be consistent with other suffixes (simply the %{name} of the compiler package) and self-explanatory what implementation it is.

Yes, that would be more consistent. However, it would break compatibility with the current naming of apps and users would have to re-learn the names of the binaries :)

Also, I'd like to stress OpenMPI since AFAIK it is, all in all, the best implementation out there.

But, as the interface to the whole MPI stack is going to change anyway, it is maybe better to change to a consistent naming right away. Changed.

2. With the current directory layout (i.e. a FHS-friendly one), the

suffixes for binaries and libraries are not necessary anymore, am I right? In that case I think they are even not desirable (what MPI implementation (or no MPI) is used will be controlled by the environment-modules so this would be just annoying when writing e.g. scripts using MPI software etc.)

IMHO having the suffix is still better, that way you can run the serial version as well if you need it for something.

In scripts this is very easy, as you can use ${MPI_SUFFIX} e.g.

#!/bin/bash

# Load LAM #module load lam-x86_64 # Load Open MPI module load openmpi-x86_64 # Load MPICH2 #module load mpich2-x86_64

# Preprocess in serial mode foo < foo.in # Run calculation mpirun -np 4 foo${MPI_SUFFIX} # Run more processing mpirun -np 4 bar${MPI_SUFFIX}

3. I've modified the draft with a SHOULD: split headers into

%{name}-headers. In this case %{name}-%{mpi}-devel needs to require only %{name}-headers (otherwise %{name}-devel will pull in %{name} unnecessarily). In my POV this could be even a MUST (the depedency on the non-MPI build is really not needed). Please review the wiki diff from its history!

OK, this is in case the headers are the same in all of the cases.

Quoting "Patrice Dumas" pertusus@free.fr:

On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote:

...

As I have been dealing with quite a few Fortran packages I have realized that the current laissez-faire mentality may not be enough and a standard is needed for file placement. https://fedoraproject.org/wiki/PackagingDrafts/Fortran

Unless I don't recall well, https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir was accepted as a guideline.

That would explain the existence of %{_fmoddir} in RPM and %configure. But why is it still in PackagingDrafts?

I think that instead of a new guideline, the current should be improved. More precisely I think that the placement of .mod files should always be below %_fmoddir, and putting them right in %_fmoddir or below a subdirectory should be left to the packager, with a word telling that a subdirectory should be used if one of the a .mod file installed name is too generic. That way, .mod files rightly named will be used without adding any flag while those that can clash (or those that are to be installed in parallel) can be below a subdirectory.

Yes. However, there is still the issue about the include files - where should they be placed? %{_fmoddir} could be also used for this.

On 26.7.2009 18:40, Patrice Dumas wrote:

On Sun, Jul 26, 2009 at 07:34:41PM +0300, Jussi Lehtola wrote:

...

Quoting "Patrice Dumas"pertusus@free.fr:

That would explain the existence of %{_fmoddir} in RPM and %configure. But why is it still in PackagingDrafts?

I don't know.

It's a pain that this happens pretty often. I accidentally started a long flame some time ago when I just asked about the status of The Flags Draft, most people did not know it has been already approved.

Would it be possible for somebody from the Packaging Committee to check all the current content of PackagingDrafts/* for drafts that have been already approved? (And move them of course.)

Thanks in advance for taking time for this, I know its annoying but I think that it will take much less time for members of the Packaging Committee than for anybody else to do this!

Milos

On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote:

On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote:

...

Hello again,

As I have been dealing with quite a few Fortran packages I have realized that the current laissez-faire mentality may not be enough and a standard is needed for file placement. https://fedoraproject.org/wiki/PackagingDrafts/Fortran

Unless I don't recall well, https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir was accepted as a guideline.

Actually, this guideline is broken [1], the directory has to be versioned [2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=513985 [2] https://bugzilla.redhat.com/show_bug.cgi?id=483765

On Mon, 2009-07-27 at 21:15 +0200, Patrice Dumas wrote:

On Mon, Jul 27, 2009 at 07:18:33PM +0300, Jussi Lehtola wrote:

...

On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote:

...

Unless I don't recall well, https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir was accepted as a guideline.

Actually, this guideline is broken [1], the directory has to be versioned [2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=513985 [2] https://bugzilla.redhat.com/show_bug.cgi?id=483765

This was discussed afterwards, if I recall well, it was said that it was not necessarily broken at each gfortran release, such that we would do rebuild only when we notice a change. In fact it is said as such in the guideline:

Each gfortran release (from 4.1 to 4.2) may lead to an incompatible change in the .mod files. Therefore for each such gfortran update, this issue should be investigated, and a rebuild of the package that provide the .mod asked for on the devel announce file and done by the maintainers if needed.

Are you unhappy with that? The problem with a versionned directory is that it would lead to many unneeded rebuilds since most of the minor gcc don't break the .mod formats and there are many minor gcc releases.

Personnally, I am not opposed to having a versionned directory. In fact this would only mean a change in the _fmoddir macro definition, and maybe somebody willing to organize an automatic rebuild of all the packages installing .mod files.

That was the opinion of Jakub Jelinek, one of the gcc maintainers.

I agree with you that normally that shouldn't have any effect as rebuilds of all packages take place when gfortran is upgraded, but given that on RHEL 5.3 there are two versions of gfortran (the default 4.1 series and the tech preview, gcc43-gfortran, to be updated to gcc44-gfortran in 5.4), this might have an effect.

And, as you said, it would only require the redefinition of the _fmoddir macro and a couple of rebuilds.

I have modified my proposal to account for the versioned directory. https://fedoraproject.org/wiki/PackagingDrafts/Fortran

On Mon, 2009-07-27 at 23:30 +0200, Patrice Dumas wrote:

On Mon, Jul 27, 2009 at 11:04:54PM +0300, Jussi Lehtola wrote:

...

That was the opinion of Jakub Jelinek, one of the gcc maintainers.

But it stirred more conversation, the whole thread started at https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html I have reread it, gfortran developpers, in general didn't thought that it should be version specific.

Thanks for the link, I came to the same conclusion.

I've asked Jakub for more explanation at https://bugzilla.redhat.com/show_bug.cgi?id=513985

PackagingDrafts/global_preferred_over_define PackagingDrafts/PatchUpstreamStatus PackagingDrafts/Epoch PackagingDrafts/ExplicitRequires PackagingDrafts/Haskell (all of them have been already merged into the main guidelines,

Haskell has another page linked from there, so just archive)

+ PackagingDrafts/Symlinks to this group

-- Milos