Bug 483765

Summary:	please have libgfortran own %_libdir/gfortan %_libdir/gfortan/modules
Product:	[Fedora] Fedora	Reporter:	Patrice Dumas <pertusus>
Component:	gcc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	11	CC:	dakingun, jakub, orion, pertusus, susi.lehtola, tcallawa
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-10-25 22:29:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	483469, 523543

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 ***