Bug 542740

Summary: Review Request: f2c - Fortran to C/C++ conversion program
Product: [Fedora] Fedora Reporter: Carl Byington <carl>
Component: Package ReviewAssignee: Susi Lehtola <susi.lehtola>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: cz172638, fedora-package-review, hobbes1069, notting, susi.lehtola, terje.rosten
Target Milestone: ---Flags: susi.lehtola: fedora-review+
gwync: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 20090411-5.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-07 21:52:01 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: 542760, 542765, 542767    

Description Carl Byington 2009-11-30 17:25:45 UTC
Spec URL: http://five-ten-sg.com/f2c.spec
SRPM URL: http://five-ten-sg.com/f2c-20031026-3.0.2.fc12.src.rpm
Description: 
F2c converts Fortran 77 source code to C or C++ source files. If no
Fortran files are named on the command line, f2c can read Fortran from
standard input and write C to standard output.

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


This is part of my project to get ghemical and its dependencies into Fedora.

ghemical buildrequires:
   f2c
   libSC-devel
   mopac7-devel
   oglappth-devel
   libghemical-data
libghemical buildrequires:
   f2c
   libSC-devel
   mopac7-devel
mopac7 buildrequires:
   f2c
mpqc provides libSC7, libSC-devel
oglappth provides oglappth-devel
f2c provides f2c

Comment 1 Carl Byington 2009-11-30 17:35:42 UTC
It helps if I use the proper URLs.

Spec URL: http://www.five-ten-sg.com/f2c.spec
SRPM URL: http://www.five-ten-sg.com/f2c-20031026-3.0.2.fc12.src.rpm

Comment 2 Susi Lehtola 2009-11-30 20:26:45 UTC
- Move the static library to a -static subpackage (or don't ship it at all - why bother with static libraries?).

- You are mixing styles, i.e. $RPM_BUILD_ROOT vs. %{buildroot}, $RPM_OPT_FLAGS vs. %{optflags}.

- I think you can safely drop the alpha stuff ("%ifarch axp" and %patch0). Otherwise, add a comment to the spec about the patch.

- If you drop the patch, replace
 make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" MFLAG="$MFLAG"
with
 make CFLAGS="%{optflags}"

- Please use
 %{_bindir}/f2c
 %{_includedir}/f2c.h
instead of using wildcards when referring to single files. Don't mix %{name} and f2c interchangeably in the spec.

- Preserve time stamps in %install with "install -p".

- Don't use "install -s" which strips the binary.

- You don't need to create the installation directories with
 mkdir -p %{buildroot}%{_libdir}
 mkdir -p %{buildroot}%{_includedir}
 mkdir -p %{buildroot}%{_bindir}
 mkdir -p %{buildroot}/%{_mandir}/man1
if you just use install -D.

=> e.g.
 %install
 rm -rf %{buildroot}
 install -D -p -m 644 libf2c/libf2c.a %{buildroot}%{_libdir}/libf2c.a
 install -D -p -m 644 f2c.h %{buildroot}%{_includedir}/f2c.h
 install -D -p -m 755 src/f2c %{buildroot}%{_bindir}/f2c
 install -D -p -m 644 src/f2c.1t %{buildroot}/%{_mandir}/man1/f2c.1
 install -D -p -m 755 libf2c/libf2c.so.0.22 %{buildroot}%{_libdir}/libf2c.so.0.22
 ln -sf libf2c.so.0.22 %{buildroot}%{_libdir}/libf2c.so

- I guess you can tidy the changelog by removing the oldest entries that are not versioned.

- rpmlint is not clean:
f2c.src: W: summary-ended-with-dot The f2c Fortran to C/C++ conversion program and static libraries.
f2c.src: W: name-repeated-in-summary f2c
f2c.src:12: W: unversioned-explicit-obsoletes f2c-libs
f2c.x86_64: W: summary-ended-with-dot The f2c Fortran to C/C++ conversion program and static libraries.
f2c.x86_64: W: name-repeated-in-summary f2c
f2c.x86_64: W: obsolete-not-provided f2c-libs
f2c.x86_64: E: no-ldconfig-symlink /usr/lib64/libf2c.so.0.22
f2c.x86_64: W: shared-lib-calls-exit /usr/lib64/libf2c.so.0.22 exit.5
f2c.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libf2c.so
f2c.x86_64: W: devel-file-in-non-devel-package /usr/include/f2c.h
f2c.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libf2c.a
3 packages and 0 specfiles checked; 1 errors, 10 warnings.

Comment 3 Susi Lehtola 2009-11-30 20:28:54 UTC
- You don't need to obsolete f2c-libs anymore. Drop it.

- You don't need to care about the shared-lib-calls-exit warning.


Once you have fixed the issues raised above, I will do the full review.

Comment 4 Carl Byington 2009-11-30 23:56:21 UTC
Those should all be fixed in:

http://www.five-ten-sg.com/f2c.spec
http://www.five-ten-sg.com/f2c-20031026-3.0.3.fc12.src.rpm

Comment 5 Susi Lehtola 2009-12-01 00:03:22 UTC
- Instead of
 %define libname     f2c-libs
 %package -n %{libname}
 %files -n %{libname}
just use
 %package libs
 %files libs
and so on.

- You don't need
Provides:   %{name}-devel = %{version}-%{release}
since the -devel package will be already %{name}-%{devel}.

- Version the requires fully in the -devel package, i.e.
 Requires:   %{libname} = %{version}-%{release}

Comment 6 Carl Byington 2009-12-01 01:47:06 UTC
Those should all be fixed in:

http://www.five-ten-sg.com/f2c.spec
http://www.five-ten-sg.com/f2c-20031026-3.0.3.fc12.src.rpm

Comment 7 Terje Røsten 2009-12-01 08:30:34 UTC
I don't see the need to continue the strange release tag, 
just change 3.0.3 to 4.

Comment 8 Susi Lehtola 2009-12-01 09:04:46 UTC
(In reply to comment #7)
> I don't see the need to continue the strange release tag, 
> just change 3.0.3 to 4.  

Yes, I agree. You could even reset it to 1, since the package hasn't been in Fedora for ages.

**

By the way, you're using Source, but Patch0. Please be consistent, and use Source0 or drop the 0 from the patch.

**

Looking at "changes" on netlib, the latest entry is

Sat Apr 11 18:06:00 MDT 2009
  src/sysdep.c src/sysdeptest.c: tweak for MacOSX (include <unistd.h>).

so the version field should be updated to correspond to it (and the source be updated if you are using the version from the old spec file).

Comment 9 Carl Byington 2009-12-02 02:59:09 UTC
Source updated from netlib, 0 dropped from patch, patch redone to correspond to the latest source, release tag reset to 1, alpha arch dropped. This latest f2c seems to be compatible with the rest of ghemical.

http://www.five-ten-sg.com/f2c.spec
http://www.five-ten-sg.com/f2c-20090411-1.fc12.src.rpm

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

Comment 10 Susi Lehtola 2009-12-02 10:12:13 UTC
f2c-devel.x86_64: W: no-documentation
f2c-libs.x86_64: E: no-ldconfig-symlink /usr/lib64/libf2c.so.0.22
f2c-libs.x86_64: W: shared-lib-calls-exit /usr/lib64/libf2c.so.0.22 exit.5
f2c-libs.x86_64: W: no-documentation
f2c-libs.x86_64: E: library-without-ldconfig-postin /usr/lib64/libf2c.so.0.22
f2c-libs.x86_64: E: library-without-ldconfig-postun /usr/lib64/libf2c.so.0.22
5 packages and 0 specfiles checked; 3 errors, 3 warnings.

- The post and postun 
 %post -p /sbin/ldconfig
 %postun -p /sbin/ldconfig
should be
 %post libs -p /sbin/ldconfig
 %postun libs -p /sbin/ldconfig

- I think the no-ldconfig-symlink warning can be fixed by creating
 ln -sf libf2c.so.0.22 %{buildroot}%{_libdir}/libf2c.so.0
Try if this works.

Comment 11 Susi Lehtola 2009-12-02 10:17:19 UTC
Oh, and move the license files (and any other general files) to the -libs package, since the -libs package is going to be always present. The documentation specific to f2c stays in the main package, and the documentation to the headers and development libraries go to -devel.

Comment 12 Susi Lehtola 2009-12-02 10:17:48 UTC
Of course, not having documentation in some subpackage is OK, if there is nothing to be put there.

Comment 13 Carl Byington 2009-12-02 16:19:30 UTC
I don't see any documentation files specific to the -libs package.

Currently f2c does not require f2c-libs, and f2c-libs does not require f2c. Should I add a requires to force one or the other, so that the license files will always get installed? 

A similar question for mpqc. The only interpackage dependencies are mpqc-devel requires mpqc-libs requires mpqc-data. The license files are installed in mpqc, so if only mpqc-libs is installed, the user has no license files. What is the general approach to such packages with multiple mostly independent subpackages. It seems there are only three choices. Force an artifical dependency on the subpackage that contains the license files, install multiple copies of the license files in each independent subpackage, or allow some subpackages to install with no license files.

Comment 14 Susi Lehtola 2009-12-02 17:30:08 UTC
(In reply to comment #13)
> Currently f2c does not require f2c-libs, and f2c-libs does not require f2c.
> Should I add a requires to force one or the other, so that the license files
> will always get installed? 
> 
> A similar question for mpqc. The only interpackage dependencies are mpqc-devel
> requires mpqc-libs requires mpqc-data. The license files are installed in mpqc,
> so if only mpqc-libs is installed, the user has no license files. What is the
> general approach to such packages with multiple mostly independent subpackages.
> It seems there are only three choices. Force an artifical dependency on the
> subpackage that contains the license files, install multiple copies of the
> license files in each independent subpackage, or allow some subpackages to
> install with no license files.  

When the packages are configured to use shared libraries, the lib dependencies will always be there. For instance 
 $ rpm -qp --requires mpqc-2.3.1-12.fc12.x86_64.rpm 
 /usr/bin/env  
 /usr/bin/wish  
 libSCbasis.so.7()(64bit)  
 libSCclass.so.7()(64bit)  
 libSCcontainer.so.7()(64bit)  
 libSCdft.so.7()(64bit)  
and so on. The lib dependencies pull in the -libs package, along with its licenses.

Independent packages must contain all (relevant) documentation in every package, but we avoid duplication of files in interdependent packages.

Comment 15 Carl Byington 2009-12-02 18:02:30 UTC
Ok for mpqc, but not f2c.

rpm -q --requires f2c
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libc.so.6(GLIBC_2.7)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1

it seems that f2c does not actually link against the libf2c shared libraries. Looking at the source, f2c itself does not use any of the code in libf2c. I think the c code *generated* by f2c needs the libf2c libraries.

Comment 16 Susi Lehtola 2009-12-02 18:12:11 UTC
(In reply to comment #15)
> Ok for mpqc, but not f2c.
> 
> 
> it seems that f2c does not actually link against the libf2c shared libraries.
> Looking at the source, f2c itself does not use any of the code in libf2c. I
> think the c code *generated* by f2c needs the libf2c libraries.  

Well.. That's odd. OK, maybe libf2c contains some intrinsic Fortran functions, that are then called in the C code produced by f2c.

Anyway, this means you will have to put in explicit dependencies. Better yet to version them fully. i.e. the main package has to
 Requires: %{name}-libs = %{version}-%{release}
and the devel package just
 Requires: %{name} = %{version}-%{release}
which pulls in f2c, which pulls in f2c-libs.

Comment 17 Carl Byington 2009-12-03 00:01:06 UTC
Ok, requires added, both main and -devel require -libs which contains the license related files. The other f2c documentation is still in the main package.

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

Comment 18 Susi Lehtola 2009-12-03 07:56:09 UTC
(In reply to comment #17)
> Ok, requires added, both main and -devel require -libs which contains the
> license related files. The other f2c documentation is still in the main
> package.
> 
> scratch build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1844942  

Umm.. what about the spec and srpm?

Comment 19 Terje Røsten 2009-12-03 08:13:56 UTC
I wonder if this -libs -devel split makes sense for this package.

Using f2c means that you want to convert Fortran code to C code, to
actually compile the result of that you need -libs *and* -devel package
as f2c will always add

#include "f2c.h"

to C output. 

Only f2c and f2c-devel is not useful, you have to add f2c-devel
to make use of f2c-libs.

f2c alone is only useful if you want to see the ugly converted output and do nothing more (very unlikely).

Splitting f2c will be the same as splitting gcc in gcc (/usr/bin/gcc),
gcc-libs (for the object files) and gcc-devel (headers).

To me this don't make sense.

Comment 20 Terje Røsten 2009-12-03 08:16:29 UTC
> 
> Umm.. what about the spec and srpm?  

Click links under "Descendent Tasks build". 
Then scroll down and you see a link to a srpm.

This works ok for some days untill koji removes the links :-)

Comment 21 Susi Lehtola 2009-12-03 08:23:18 UTC
(In reply to comment #19)
> I wonder if this -libs -devel split makes sense for this package.

It does.

> Using f2c means that you want to convert Fortran code to C code, to
> actually compile the result of that you need -libs *and* -devel package
> as f2c will always add
> 
> #include "f2c.h"
> 
> to C output. 
> 
> Only f2c and f2c-devel is not useful, you have to add f2c-devel
> to make use of f2c-libs.

No, you have to add f2c-devel to use f2c. So actually one could unite f2c-devel with f2c, which would just have a virtual Provides: f2c-devel.

Anyway, if you build something with f2c, then the resulting package will only need the shared library, that is provided by f2c-libs.

Comment 22 Susi Lehtola 2009-12-03 08:24:09 UTC
(In reply to comment #20)
> > 
> > Umm.. what about the spec and srpm?  
> 
> Click links under "Descendent Tasks build". 
> Then scroll down and you see a link to a srpm.
> 
> This works ok for some days untill koji removes the links :-)  

Yes, but still I don't want to build (or install) the srpm just to have a look at the spec file.

Comment 23 Susi Lehtola 2009-12-03 08:38:56 UTC
Besides, you haven't increased the release tag. Increment the release and add relevant comments to the changelog every time you make changes to the spec file.

Comment 24 Susi Lehtola 2009-12-03 08:46:45 UTC
Make the link as instructed in comment #10. It fixes the rpmlint error
f2c-libs.x86_64: E: no-ldconfig-symlink /usr/lib64/libf2c.so.0.22

Actually, you might want to change the arguments of the link commands from -sf to -s, since the latter is safer.

**

You don't need to patch the makefile for CFLAGS, running
 make CFLAGS="%{optflags}"
overrides them in any case. Also the change of CC is not necessary.

And you can drop the MFLAG declaration, it isn't used anywhere!

**

The patch still needs a comment in the spec file.

Comment 25 Susi Lehtola 2009-12-03 08:49:56 UTC
And the Requires are still not perfect. So, actually the main package has to also
 Requires: %{name}-devel = %{version}-%{release}
since the headers are needed for normal operation.

Change the summary to "A Fortran 77 to C/C++ conversion program", since f2c doesn't work with any of the more modern versions of Fortran.

Comment 26 Susi Lehtola 2009-12-03 08:59:21 UTC
And for the sake of consistency I'd use
 %{_libdir}/libf2c.so.*
in %files :)

After these have been fixed, the review should pass with flying colors.

Comment 27 Susi Lehtola 2009-12-03 09:08:11 UTC
(In reply to comment #26)
> And for the sake of consistency I'd use
>  %{_libdir}/libf2c.so.*
> in %files :)

and for the same reason use f2c instead of %{name} in
 %{_bindir}/%{name}

Comment 28 Carl Byington 2009-12-04 05:12:15 UTC
"The patch still needs a comment in the spec file." Not sure what you want there, but I added a note in the changelog.



- add symlink to fix rpmlint error
- remove unnecessary parts of the patch, which enables building a
  shared library.
- main package now requires -devel since that is needed to be useful.
- summary changed to specify this only works on F77 code.
- %%files use explicit libf2c rather than * wildcard

http://www.five-ten-sg.com/f2c.spec
http://www.five-ten-sg.com/f2c-20090411-2.fc12.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=1848552

Comment 29 Susi Lehtola 2009-12-04 10:29:25 UTC
(In reply to comment #28)
> "The patch still needs a comment in the spec file." Not sure what you want
> there, but I added a note in the changelog.

I mean this
 # Patch makefile to build a shared library
 Patch: f2c-20090411.patch
Also, the patch backup would better reflect the patch by naming it .sharedlib instead of .tim. 

- I think the devel package still has to require %{name} = %{version}-%{release}. Are there any pieces of software that don't use f2c, only the libraries..? Then again, I never have used f2c.

**

rpmlint output:
f2c.x86_64: E: devel-dependency f2c-devel
f2c-devel.x86_64: W: no-documentation
f2c-libs.x86_64: W: shared-lib-calls-exit /usr/lib64/libf2c.so.0.22 exit.5
5 packages and 0 specfiles checked; 1 errors, 2 warnings.

These are all OK.

**

MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK
MUST: The spec file for the package is legible and macros are used consistently. OK
MUST: The package must be named according to the Package Naming Guidelines. OK
MUST: The spec file name must match the base package %{name}. OK
MUST: The package must be licensed with a Fedora approved license and meet the  Licensing Guidelines. OK
MUST: The License field in the package spec file must match the actual license. OK
MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. OK
MUST: The package MUST successfully compile and build into binary rpms. OK
MUST: The spec file MUST handle locales properly. N/A
MUST: Optflags are used and time stamps preserved. OK
MUST: Packages containing shared library files must call ldconfig. OK
MUST: A package must own all directories that it creates or require the package that owns the directory. OK
MUST: Files only listed once in %files listings. OK
MUST: Debuginfo package is complete. OK
MUST: Permissions on files must be set properly. OK
MUST: Clean section exists. OK
MUST: Large documentation files must go in a -doc subpackage. N/A
MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. OK
MUST: Header files must be in a -devel package. OK
MUST: Static libraries must be in a -static package. N/A
MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A
MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. OK
MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. OK
MUST: Packages does not contain any .la libtool archives. N/A
MUST: Desktop files are installed properly. N/A
MUST: No file conflicts with other packages and no general names. OK
MUST: Buildroot cleaned before install. OK
SHOULD: %{?dist} tag is used in release. OK
SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. OK
SHOULD: The package builds in mock. OK

The package has been APPROVED.

Comment 30 Carl Byington 2009-12-05 17:25:59 UTC
Since -devel requires main is required by the standards above, I propose:

-devel requires main requires -libs. That forces installation of -libs containing the licenses, but code built by f2c and compiled by gcc only needs -libs to run. 

You can then install just main, and use f2c to generate c code, but that code won't actually compile unless you install -devel, since it needs the headers to compile. We could re-add the current 'main requires -devel' but that leads to main and -devel requiring each other (which is strange) or merging main and -devel (which conflicts with the standard requirement of .so files must be in -devel subpackage).

If we switch to '-devel requires main requires -libs', then packages that need f2c to build will need 'buildrequires f2c-devel' rather than their current buildrequires f2c.

Comment 31 Susi Lehtola 2009-12-05 22:18:45 UTC
(In reply to comment #30)
> You can then install just main, and use f2c to generate c code, but that code
> won't actually compile unless you install -devel, since it needs the headers to
> compile. We could re-add the current 'main requires -devel' but that leads to
> main and -devel requiring each other (which is strange) or merging main and
> -devel (which conflicts with the standard requirement of .so files must be in
> -devel subpackage).

Indeed, the -devel requires main requires -devel is strange behavior, when you look at it from a fresh point of view.

The guidelines are not strict in this case; for e.g. compilers it is normal to put development libraries in the main package.

So actually it would be best to unite -devel with main and make the main package Provides: f2c-devel.

Comment 32 Carl Byington 2009-12-05 23:37:32 UTC
fixed.

http://www.five-ten-sg.com/f2c.spec
http://www.five-ten-sg.com/f2c-20090411-2.fc12.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=1851912

f2c.src:14: W: unversioned-explicit-provides %{name}-devel

should that provides be made explicit?

Comment 33 Carl Byington 2009-12-05 23:39:01 UTC
wrong copy/paste, should be f2c-20090411-4.fc12.src.rpm

http://www.five-ten-sg.com/f2c.spec
http://www.five-ten-sg.com/f2c-20090411-4.fc12.src.rpm

Comment 34 Susi Lehtola 2009-12-06 09:49:21 UTC
(In reply to comment #32)
> f2c.src:14: W: unversioned-explicit-provides %{name}-devel
> 
> should that provides be made explicit?  

It should be versioned, i.e. Provides: %{name}-devel = %{version}-%{release}.

Comment 35 Susi Lehtola 2009-12-06 09:50:07 UTC
The review is still OK. Apply for CVS branches.

Comment 36 Carl Byington 2009-12-06 18:11:58 UTC
New Package CVS Request
=======================
Package Name: f2c
Short Description: A Fortran 77 to C/C++ conversion program
Owners: carllibpst
Branches: F-12
InitialCC:

Comment 37 Susi Lehtola 2009-12-06 18:24:58 UTC
(In reply to comment #15)
> Ok for mpqc, but not f2c.
> 
> rpm -q --requires f2c
> libc.so.6
> libc.so.6(GLIBC_2.0)
> libc.so.6(GLIBC_2.1)
> libc.so.6(GLIBC_2.1.3)
> libc.so.6(GLIBC_2.2)
> libc.so.6(GLIBC_2.3)
> libc.so.6(GLIBC_2.3.4)
> libc.so.6(GLIBC_2.4)
> libc.so.6(GLIBC_2.7)
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rtld(GNU_HASH)
> rpmlib(PayloadIsXz) <= 5.2-1

Funny. I get:
$ rpm -q --requires f2c
f2c-libs = 20090411-4.fc12
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libc.so.6(GLIBC_2.7)(64bit)  
libf2c.so.0()(64bit)  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)  
rpmlib(PayloadIsXz) <= 5.2-1

Here the libf2c.so.0()(64bit) part is picked up automatically. So in my opinion you can drop the explicit requirement.

Btw, do you have redhat-rpm-config installed on your system..?

Or, if you want to be on the safe side, you can make the dep arch explicit:
 Requires: f2c-libs%{_isa} = %{version}-%{release}
This would require that you install the 64-bit -libs with the 64-bit f2c package, even if you have the 32-bit -libs package present.

Anyway, this doesn't really have anything to do with the review any more.

Comment 38 Susi Lehtola 2009-12-06 18:36:25 UTC
No F-11..?

Comment 39 Carl Byington 2009-12-06 18:54:21 UTC
I was not sure on policy on adding new packages to n-1. If that is ok then I would also like an F11 branch also.

Comment 40 Susi Lehtola 2009-12-06 19:40:06 UTC
(In reply to comment #39)
> I was not sure on policy on adding new packages to n-1. If that is ok then I
> would also like an F11 branch also.  

So in that case

New Package CVS Request
=======================
Package Name: f2c
Short Description: A Fortran 77 to C/C++ conversion program
Owners: carllibpst
Branches: F-11 F-12
InitialCC:  

so that the CVS admins find it.

Comment 41 Kevin Fenzi 2009-12-06 23:23:34 UTC
cvs done.

Comment 42 Susi Lehtola 2009-12-19 23:33:07 UTC
ping, submit the updates on F-11 and F-12. Remember to fill in this bug number in the bug field of the updates.

Comment 43 Carl Byington 2009-12-20 23:27:38 UTC
done.

Comment 44 Fedora Update System 2009-12-22 04:45:49 UTC
f2c-20090411-5.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update f2c'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-13448

Comment 45 Fedora Update System 2009-12-22 04:46:32 UTC
f2c-20090411-5.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update f2c'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13454

Comment 46 Fedora Update System 2010-01-07 21:51:55 UTC
f2c-20090411-5.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 47 Fedora Update System 2010-01-07 21:53:02 UTC
f2c-20090411-5.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 48 Richard Shaw 2015-01-08 00:01:11 UTC
Package Change Request
======================
Package Name: f2c
New Branches: epel7
Owners: hobbes1069 carllibpst
InitialCC:

Comment 49 Gwyn Ciesla 2015-01-08 13:49:49 UTC
Git done (by process-git-requests).

Comment 50 Jiri Kastner 2015-04-29 11:45:42 UTC
Package Change Request
======================
Package Name: f2c
New Branches: el6
Owners: hobbes1069 carllibpst jkastner
InitialCC:

Comment 51 Gwyn Ciesla 2015-04-29 13:09:06 UTC
Git done (by process-git-requests).