The Fortran Modules Directory Packaging Guideline states that Fortran modules must be placed in %{_fmoddir}. https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir (It's still in Drafts since someone forgot to move it to Packaging.) The directory should be owned by gcc-gfortran; currently no package provides it.
That Guideline is broken, modules are Gfortran version specific, therefore they should go into gfortran version specific directory designed for that purpose and already owned by gfortran. See #483765.
It was discussed with gfortran maintainers, https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html Anyway, I assume that /usr/lib/gcc/<target>/<version>/finclude is better than %{_libdir}/gfortran/modules since it is automatically included by gfortran? It occurs to me that you were the only one defending the use of a gfortran-versioned directory. How about multilib architectures? https://www.redhat.com/archives/fedora-packaging/2007-October/msg00034.html ? Currently I get $ gcc -m32 -print-file-name=finclude /usr/lib/gcc/x86_64-redhat-linux/4.4.0/finclude $ gcc -m64 -print-file-name=finclude /usr/lib/gcc/x86_64-redhat-linux/4.4.0/finclude on Fedora 11 x86_64. The version specificity is really not an issue, since anyway all packages are rebuilt whenever a (major) version change occurs in GCC, right? (And if one is using the tech preview compilers on RHEL, then one is not going to use %{_fmoddir} anyway.)
Reopening to get reply to comment #2.
ping jakub? The FPC is going to discuss http://www.fedoraproject.org/wiki/PackagingDrafts/Fortran tomorrow (Wednesday) at 1600 UTC, so it would be nice to get this thing sorted out before that.
Ping. The Fortran guidelines above have been ratified by FESCo, so it would be nice if you fixed this problem ASAP. http://fedoraproject.org/wiki/Packaging:Fortran The current version of %{_fmoddir} is multiarch compatible. Even though it isn't compatible with multiple versions of gfortran, there is only one default version supported anyway in Fedora and in RHEL. When gfortran is upgraded the modules must anyway be recompiled and updated.
I tried to compile openmpi with fedora 11 because i need "--with-sge" option but i can't install openmpi 1.3.1 because of otfdump and i can't compile 1.3.3 because of %{_fmoddir}. Can you add --with-sge ?
sorry, bad windows : https://bugzilla.redhat.com/show_bug.cgi?id=521334
Ping again.
*** Bug 483765 has been marked as a duplicate of this bug. ***
The relevant guideline has been changed now to http://www.fedoraproject.org/wiki/Packaging:Fortran As Orion noted in bug 483765, %{_fmoddir} is currently defined in /usr/lib/rpm/redhat/macros owned by redhat-rpm-config. If you think that %{_fmoddir} needs to be versioned, then the definition needs to be moved to the gfortran package. I'm not totally convinced that it needs to be versioned, though. Even if the modules are gfortran version specific, the packages that contain Fortran modules are recompiled whenever a (major) update of gfortran occurs (this is already done by mass rebuilds). And, if one adds versioned dependencies on gfortran on the development packages that contain Fortran modules (which needs to be done anyway), there's nothing that can go wrong even if %{_fmoddir} is not versioned.
http://www.fedoraproject.org/wiki/Packaging:Fortran states: As Fortran modules are architecture and GCC version specific, they MUST be placed into %{_fmoddir} (or its package-specific subfolder in case the modules have generic names), which is owned by 'gcc-gfortran'. For directory ownership any packages containing Fortran modules MUST Requires: gcc-gfortran%{_isa}. -- For this to work, the x86_64 gfortran should also own the 32-bit %{_fmoddir}. Then it could also Provides: gfortran(x86-32) (and the same thing on other arches, too) or the guideline could be just be Requires: gcc-gfortran since both directories would be provided.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 483466 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Jakub - Is there any reason not to do this? Please comment. Otherwise I'm going to check in the change. It would be nice to get this addressed after 4 years...
I'd settle for changing %_fmoddir to the Gfortran internal directory, that's probably better anyway. See 983057. *** This bug has been marked as a duplicate of bug 983057 ***
see bug 1113564