I do not haven enough knowledge of Fortran to get this done. Can you please provide a few more details?

What is the matching provide in the gcc-gfortran package that should be required?
Are the modules all located in /usr/lib(64)?/gfortran/modules/ ?
Are they all gzip compressed?
Do you really have to have gcc-gfortran installed for the modules to be useful?
What about people installing another version from a third party?
Is there a different Fortran implementation we need to care about?

It would look like the module files are all gzip compressed text. You do need gcc-gfortran for the modules to make sense, since they're header files. There's no different Fortran implementation we need to care about, and no need to care about third parties.

For the module files to be useful, you need the matching version of gcc-gfortran. I'll have to refer to the GCC maintainers (cc Jakub) to answer how to get the necessary gcc-gfortran require, as well as to refine the answers above.

Created attachment 1038872 [details]
fortranmodule fileattribute

Needs to go into /usr/lib/rpm/fileattrs/

Created attachment 1038873 [details]
Dependency generator for fortran modules

Needs to go into /usr/lib/rpm/

The generated Requires are not final as there is no one there to actually provide them yet.

Ok, I attached the first version of the dependency generation mechanics. But unless there is a provide or a matching from Fortran versions to gcc-gfortran versions the versioning won't work.

A simple solution would be to just require gcc-gfortran without a version but I guess this kinda defeats the purpose of the RFE.

As I am not a Fortran person this is basically untested - except from a first smoke test. May be someone from the Fortran SIG can step in there.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Is this still being worked on? Or can we just close this?

Sorry, without some cooperation of packagers this won't fly. Feel free to reopen if you really want to get this done and are willing and able participate.

Uhm, did you want something from me? Sounded more like you need the help of gfortran maintainers..

Yeah, lets fix this in gcc:

diff --git a/fortranmodule.attr b/fortranmodule.attr
new file mode 100644
index 0000000..83ed0c8
--- /dev/null
+++ b/fortranmodule.attr
@@ -0,0 +1,3 @@
+%__fortranmodule_requires       %{_rpmconfigdir}/fortranmodule.req
+%__fortranmodule_path           ^%{_libdir}/gfortran/modules/.*\.mod$
+%__fortranmodule_magic          ^gzip compressed data, from Unix$
diff --git a/fortranmodule.req b/fortranmodule.req
new file mode 100644
index 0000000..24176e3
--- /dev/null
+++ b/fortranmodule.req
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+while read filename; do
+      gunzip $filename -c| sed -n -e "1s:^GFORTRAN module version '\{1,\}\([[:digit:]]\{1,\}\)' created from .*$:gfortran-module-version = \1:p"
+done
diff --git a/gcc.spec b/gcc.spec
index 152d1f6..a4230d9 100644
--- a/gcc.spec
+++ b/gcc.spec
@@ -3,11 +3,14 @@
 %global gcc_version 5.3.1
 # Note, gcc_release must be integer, if you want to add suffixes to
 # %{release}, append them after %{gcc_release} on Release: line.
-%global gcc_release 3
+%global gcc_release 4
 %global _unpackaged_files_terminate_build 0
 %global _performance_build 1
 # Hardening slows the compiler way too much.
 %undefine _hardened_build
+# MOD_VERSION from gcc/fortran/module.c
+# sed -n '/^#define *MOD_VERSION/s/^.*"\([0-9]*\)".*$/\1/p' gcc/fortran/module.c
+%global gfortran_module_version 14
 %global multilib_64_archs sparc64 ppc64 ppc64p7 s390x x86_64
 %ifarch %{ix86} x86_64 ia64 ppc ppc64 ppc64p7 alpha %{arm} aarch64
 %global build_ada 1
@@ -96,6 +99,8 @@ Group: Development/Languages
 # svn export svn://gcc.gnu.org/svn/gcc/branches/redhat/gcc-5-branch@%{SVNREV} gcc-%{version}-%{DATE}
 # tar cf - gcc-%{version}-%{DATE} | bzip2 -9 > gcc-%{version}-%{DATE}.tar.bz2
 Source0: gcc-%{version}-%{DATE}.tar.bz2
+Source1: fortranmodule.attr
+Source2: fortranmodule.req
 %global isl_version 0.14
 URL: http://gcc.gnu.org
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -339,6 +344,7 @@ Requires: libquadmath-devel = %{version}-%{release}
 %endif
 Requires(post): /sbin/install-info
 Requires(preun): /sbin/install-info
+Provides: gfortran-module-version = %{gfortran_module_version}
 Autoreq: true
 
 %description gfortran
@@ -904,6 +910,12 @@ if [ -d libstdc++-v3/config/abi/post/sparc64-linux-gnu ]; then
 fi
 %endif

+# Check that gfortran_module_version is correct
+gfortran_module_version="$(sed -n '/^#define *MOD_VERSION/s/^.*"\([0-9]*\)".*$/\1/p' gcc/fortran/module.c)"
+[ "$gfortran_module_version" != %gfortran_module_version ] &&
+  echo "ERROR: gfortran-module-version %gfortran_module_version does not match source -> $gfortran_module_version" &&
+  exit 1
+
 # This test causes fork failures, because it spawns way too many threads
 rm -f gcc/testsuite/go.test/test/chan/goroutines.go

@@ -1865,6 +1877,11 @@ rm -f %{buildroot}%{mandir}/man3/ffi*
 # Help plugins find out nvra.
 echo gcc-%{version}-%{release}.%{_arch} > $FULLPATH/rpmver

+# Install rpm fileattr scripts
+mkdir -p %{buildroot}%{_fileattrsdir}
+install -p -m 0644 %SOURCE1 %{buildroot}%{_fileattrsdir}/
+install -p -m 0755 %SOURCE2 %{buildroot}%{_rpmconfigdir}/
+
 %check
 cd obj-%{gcc_target_platform}

@@ -2609,6 +2626,8 @@ fi
 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/finclude
 %endif
 %dir %{_fmoddir}
+%{_fileattrsdir}/fortranmodule.attr
+%{_rpmconfigdir}/fortranmodule.req
 %doc rpm.doc/gfortran/*

 %files -n libgfortran
@@ -3052,6 +3071,10 @@ fi
 %doc rpm.doc/changelogs/libcc1/ChangeLog*

 %changelog
+* Fri Jan  8 2016 Orion Poplawski <orion.com> 5.3.1-4
+- Add RPM requires generator for gfortran modules (bug #1192617)
+- Provide gfortran-module-version
+
 * Tue Jan  5 2016 Orion Poplawski <orion.com> 5.3.1-3
 - Make gcc-gfortran own %%{_fmoddir} (#1113564)


I don't see any way around manually updating gfortran_module_version in the spec, but the automatic check in %prep will detect any discrepancies fairly early.

scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=12473754

Yes, looks like we're near the solution.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

*** Bug 1419278 has been marked as a duplicate of this bug. ***

*** Bug 1419489 has been marked as a duplicate of this bug. ***

Any update on this? It seems I cannot compile hpl package due to this (original bug 1419489).

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Error: 
 Problem: package hdf5-devel-1.8.18-11.fc28.x86_64 requires libhdf5.so.10()(64bit), but none of the providers can be installed
  - conflicting requests
  - nothing provides libgfortran.so.4()(64bit) needed by hdf5-1.8.18-11.fc28.x86_64


Is this related?  I can't use hdf5-devel as a dependency in other packages at the moment.

(In reply to Philip Kovacs from comment #17)
> Error: 
>  Problem: package hdf5-devel-1.8.18-11.fc28.x86_64 requires
> libhdf5.so.10()(64bit), but none of the providers can be installed
>   - conflicting requests
>   - nothing provides libgfortran.so.4()(64bit) needed by
> hdf5-1.8.18-11.fc28.x86_64
> 
> 
> Is this related?  I can't use hdf5-devel as a dependency in other packages
> at the moment.

I have similar problem when recompiling HPL:
DEBUG util.py:439:  Error: 
DEBUG util.py:439:   Problem: package openmpi-devel-2.1.1-5.fc28.x86_64 requires libmpi.so.20()(64bit)(openmpi-x86_64), but none of the providers can be installed
DEBUG util.py:439:    - conflicting requests
DEBUG util.py:439:    - nothing provides libgfortran.so.4()(64bit) needed by openmpi-2.1.1-5.fc28.x86_64

In my case probably openmpi rebuild will resolve it, because it's now libgfortran.so.5 in f28. In your case probably hdf5 rebuild will resolve it.

(In reply to Philip Kovacs from comment #17)
> Error: 
>  Problem: package hdf5-devel-1.8.18-11.fc28.x86_64 requires
> libhdf5.so.10()(64bit), but none of the providers can be installed
>   - conflicting requests
>   - nothing provides libgfortran.so.4()(64bit) needed by
> hdf5-1.8.18-11.fc28.x86_64
> 
> Is this related?  I can't use hdf5-devel as a dependency in other packages
> at the moment.

It is *not*. That's a library dependency, which rpm does know about - which is why you get the error.

This bug is about Fortran development modules, which are also versioned but that version dependency isn't picked up by rpm.

Yes, looks like the rebuild of 1/31/2018 did clear up the fortran dependency problem I mentioned above.

https://apps.fedoraproject.org/koschei/package/hdf5

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. 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 EOL if it remains open with a Fedora  'version'
of '26'.

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.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 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, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

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.

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
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 EOL if it remains open with a
Fedora 'version' of '29'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
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 EOL if it remains open with a
Fedora 'version' of '32'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
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 EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.