Bug 483765 - please have libgfortran own %_libdir/gfortan %_libdir/gfortan/modules
Summary: please have libgfortran own %_libdir/gfortan %_libdir/gfortan/modules
Keywords:
Status: CLOSED DUPLICATE of bug 513985
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 11
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 483469 523543
TreeView+ depends on / blocked
 
Reported: 2009-02-03 14:59 UTC by Patrice Dumas
Modified: 2009-10-25 22:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-25 22:29:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Patrice Dumas 2009-02-03 14:59:13 UTC
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 10:33:12 UTC
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 16:15:24 UTC
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 16:24:44 UTC
(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 18:41:09 UTC
To version or not to version?

Comment 5 Bug Zapper 2009-06-09 11:03:08 UTC
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 14:42:43 UTC
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 21:23:05 UTC
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 22:29:09 UTC
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.