Bug 483765 - please have libgfortran own %_libdir/gfortan %_libdir/gfortan/modules
please have libgfortran own %_libdir/gfortan %_libdir/gfortan/modules
Status: CLOSED DUPLICATE of bug 513985
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
11
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 483469 523543
  Show dependency treegraph
 
Reported: 2009-02-03 09:59 EST by Patrice Dumas
Modified: 2009-10-25 18:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-25 18:29:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrice Dumas 2009-02-03 09:59:13 EST
Description of problem:

It would be nice if libraries shipping a .mod file didn't all have to own. 
%_libdir/gfortan %_libdir/gfortan/modules
I think that it would better be owned by libgfortran since the .mod describe the ABI.

See also
http://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
Bug 483469

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jakub Jelinek 2009-02-11 05:33:12 EST
Given that the module format is gfortran version specific, sticking them into a directory not specific to gfortran version is IMHO very bad idea.
Use
/usr/lib/gcc/<target>/<version>/finclude
directory instead, which is version specific and already searched by gfortran by default.
Comment 2 Patrice Dumas 2009-02-11 11:15:24 EST
This is not the approach that was agreed upon when devising the guideline:
http://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir

At that time, the idea was that in reality the .mod files were not different each release, so depending on the gcc version and rebuilding each time was not useful.

Do you disagree with the guideline (that is, the .mod file and the corresponding package should depend on the gcc-gfortran %version version)? This means a lot of rebuilds.

Which package owns /usr/lib/gcc/<target>/<version>/finclude?
Comment 3 Orion Poplawski 2009-02-11 11:24:44 EST
(In reply to comment #2)
> Which package owns /usr/lib/gcc/<target>/<version>/finclude?

# rpm -qf /usr/lib/gcc/i386-redhat-linux/4.3.2/finclude
gcc-gfortran-4.3.2-7.i386

Not an unreasonable package to require if we indeed need to got the versioned directory route.
Comment 4 Orion Poplawski 2009-02-20 13:41:09 EST
To version or not to version?
Comment 5 Bug Zapper 2009-06-09 07:03:08 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Tom "spot" Callaway 2009-08-20 10:42:43 EDT
I think that we should version here. When the gcc maintainer says that the .mod files are specific to the gfortran version, I'm inclined to trust him. :)
Comment 7 Orion Poplawski 2009-09-15 17:23:05 EDT
So, how exactly is this going to work?  Currently %_fmoddir is defined in /usr/lib/rpm/redhat/macros owned by redhat-rpm-config.  If this is going to be a versioned directory that changes with gcc version, it should move to /etc/rpm/macros.gfortran owned by gcc-gfortran.  Make sense?  I'm happy to push this through since this has been stalled for 6 months, but folks might not like me touching gcc and redhat-rpm-config. :-)
Comment 8 Susi Lehtola 2009-10-25 18:29:09 EDT
The relevant guideline is now
http://www.fedoraproject.org/wiki/Packaging:Fortran

and the module dir should be owned by gfortran, since you only need modules for development..

Closing as duplicate.

*** This bug has been marked as a duplicate of bug 513985 ***

Note You need to log in before you can comment on or make changes to this bug.