Bug 542740
Summary: | Review Request: f2c - Fortran to C/C++ conversion program | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Carl Byington <carl> |
Component: | Package Review | Assignee: | Susi Lehtola <susi.lehtola> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | 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
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 - 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. - 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. 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 - 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} 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 I don't see the need to continue the strange release tag, just change 3.0.3 to 4. (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). 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 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. 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. Of course, not having documentation in some subpackage is OK, if there is nothing to be put there. 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. (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. 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. (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. 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 (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? 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. >
> 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 :-)
(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. (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. 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. 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. 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. 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. (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} "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 (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. 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. (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. 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? 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 (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}. The review is still OK. Apply for CVS branches. New Package CVS Request ======================= Package Name: f2c Short Description: A Fortran 77 to C/C++ conversion program Owners: carllibpst Branches: F-12 InitialCC: (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. No F-11..? 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. (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. cvs done. ping, submit the updates on F-11 and F-12. Remember to fill in this bug number in the bug field of the updates. done. 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 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 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. 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. Package Change Request ====================== Package Name: f2c New Branches: epel7 Owners: hobbes1069 carllibpst InitialCC: Git done (by process-git-requests). Package Change Request ====================== Package Name: f2c New Branches: el6 Owners: hobbes1069 carllibpst jkastner InitialCC: Git done (by process-git-requests). |