Spec URL: http://benboeckel.net/packaging/ghc-pcre-light/ghc-pcre-light.spec SRPM URL: http://benboeckel.net/packaging/ghc-pcre-light/ghc-pcre-light-0.4-1.fc14.src.rpm Description: A small, efficient and portable regex library for Perl 5 compatible regular expressions The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. % lintmock fedora-14-x86_64 ghc-pcre-light.src: W: spelling-error %description -l en_US regex -> regexp, remex, reg ex ghc-pcre-light.x86_64: W: spelling-error %description -l en_US regex -> regexp, remex, reg ex ghc-pcre-light-devel.x86_64: W: spelling-error %description -l en_US regex -> regexp, remex, reg ex ghc-pcre-light-prof.x86_64: E: devel-dependency ghc-pcre-light-devel ghc-pcre-light-prof.x86_64: W: spelling-error %description -l en_US regex -> regexp, remex, reg ex ghc-pcre-light-prof.x86_64: W: no-documentation ghc-pcre-light-prof.x86_64: W: devel-file-in-non-devel-package /usr/lib64/ghc-6.12.3/pcre-light-0.4/libHSpcre-light-0.4_p.a 4 packages and 0 specfiles checked; 1 errors, 6 warnings.
1) These errors from rpmlint should be fixed if possible: ghc-pcre-light-prof.x86_64: E: devel-dependency ghc-pcre-light-devel ghc-pcre-light-prof.x86_64: W: devel-file-in-non-devel-package /usr/lib64/ghc-6.12.3/pcre-light-0.4/libHSpcre-light-0.4_p.a 2) There shouldn't be common_summary, common_description, and ghc_pkg_c_deps macros since these are only used once. The ghc_pkg_deps line should be removed completely because the macro is undefined. 3) I noticed that there are two options for conditional builds: shared and hscolour. Can you confirm that these are desirable? In other words, could you add a comment to the spec file describing why someone might choose to use these options?
(In reply to comment #1) > 1) These errors from rpmlint should be fixed if possible: > > ghc-pcre-light-prof.x86_64: E: devel-dependency ghc-pcre-light-devel > ghc-pcre-light-prof.x86_64: W: devel-file-in-non-devel-package > /usr/lib64/ghc-6.12.3/pcre-light-0.4/libHSpcre-light-0.4_p.a Standard Haskell packaging things. These files are used when profiling the code which implies that the -devel package exist. > 2) There shouldn't be common_summary, common_description, and ghc_pkg_c_deps > macros since these are only used once. The ghc_pkg_deps line should be removed > completely because the macro is undefined. These are also standard Haskell packaging things. I think the %{common_*} macros are used in the %{?ghc_lib_package} line which is where the -prof and -devel subpackages are defined. > 3) I noticed that there are two options for conditional builds: shared and > hscolour. Can you confirm that these are desirable? In other words, could you > add a comment to the spec file describing why someone might choose to use these > options? These are actually no longer there in the latest cabal2spec templates. I'll update the spec file to it.
(In reply to comment #2) > (In reply to comment #1) > > 1) These errors from rpmlint should be fixed if possible: > > > > ghc-pcre-light-prof.x86_64: E: devel-dependency ghc-pcre-light-devel > > ghc-pcre-light-prof.x86_64: W: devel-file-in-non-devel-package > > /usr/lib64/ghc-6.12.3/pcre-light-0.4/libHSpcre-light-0.4_p.a > > Standard Haskell packaging things. These files are used when profiling the code > which implies that the -devel package exist. Shouldn't the libHSpcre-light-0.4_p.a appear in the devel package rather than in the main package? > > 2) There shouldn't be common_summary, common_description, and ghc_pkg_c_deps > > macros since these are only used once. The ghc_pkg_deps line should be removed > > completely because the macro is undefined. > > These are also standard Haskell packaging things. I think the %{common_*} > macros are used in the %{?ghc_lib_package} line which is where the -prof and > -devel subpackages are defined. I don't see any reference to this on the Haskell packaging guidelines page: http://fedoraproject.org/wiki/Packaging/Haskell > > 3) I noticed that there are two options for conditional builds: shared and > > hscolour. Can you confirm that these are desirable? In other words, could you > > add a comment to the spec file describing why someone might choose to use these > > options? > > These are actually no longer there in the latest cabal2spec templates. I'll > update the spec file to it. Sounds great.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > 1) These errors from rpmlint should be fixed if possible: > > > > > > ghc-pcre-light-prof.x86_64: E: devel-dependency ghc-pcre-light-devel > > > ghc-pcre-light-prof.x86_64: W: devel-file-in-non-devel-package > > > /usr/lib64/ghc-6.12.3/pcre-light-0.4/libHSpcre-light-0.4_p.a > > > > Standard Haskell packaging things. These files are used when profiling the code > > which implies that the -devel package exist. > > Shouldn't the libHSpcre-light-0.4_p.a appear in the devel package rather than > in the main package? The _p is the profiling library. The -devel library does not have it. > > > 2) There shouldn't be common_summary, common_description, and ghc_pkg_c_deps > > > macros since these are only used once. The ghc_pkg_deps line should be removed > > > completely because the macro is undefined. > > > > These are also standard Haskell packaging things. I think the %{common_*} > > macros are used in the %{?ghc_lib_package} line which is where the -prof and > > -devel subpackages are defined. > > I don't see any reference to this on the Haskell packaging guidelines page: > > http://fedoraproject.org/wiki/Packaging/Haskell If you look at the spec files generated from cabal2spec, they're used there. Maybe the wiki needs some updating.
I also don't see a %files section. Is that somehow included by %{?ghc_lib_package}?
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > 1) These errors from rpmlint should be fixed if possible: > > > > > > > > ghc-pcre-light-prof.x86_64: E: devel-dependency ghc-pcre-light-devel > > > > ghc-pcre-light-prof.x86_64: W: devel-file-in-non-devel-package > > > > /usr/lib64/ghc-6.12.3/pcre-light-0.4/libHSpcre-light-0.4_p.a > > > > > > Standard Haskell packaging things. These files are used when profiling the code > > > which implies that the -devel package exist. > > > > Shouldn't the libHSpcre-light-0.4_p.a appear in the devel package rather than > > in the main package? > > The _p is the profiling library. The -devel library does not have it. So it looks like RPM is complaining because the ghc-pcre-light-prof package contains a .a file, but ghc-pcre-light-prof isn't a devel package. This seems like a legitimate error.
(In reply to comment #6) > So it looks like RPM is complaining because the ghc-pcre-light-prof package > contains a .a file, but ghc-pcre-light-prof isn't a devel package. This seems > like a legitimate error. It's standard Haskell packaging. I'll have Jens verify.
My understanding is that the prof libraries are available if someone wants to profile their code in conjunction with the libraries distributed via the devel packages. The prof libraries are not mandatory for developing code as such and hence the split up into -devel and -prof packages. Some users may not want to install prof packages (they pulls in ghc-prof, which is around 40 MB).
(In reply to comment #3) > > > ghc-pcre-light-prof.x86_64: E: devel-dependency ghc-pcre-light-devel > > > ghc-pcre-light-prof.x86_64: W: devel-file-in-non-devel-package > > > /usr/lib64/ghc-6.12.3/pcre-light-0.4/libHSpcre-light-0.4_p.a > > > > Standard Haskell packaging things. These files are used when profiling the code > > which implies that the -devel package exist. > > Shouldn't the libHSpcre-light-0.4_p.a appear in the devel package rather than > in the main package? Well we have been subpackaging profiling libraries "forever" like, since they are normally not needed for development but occasionally useful when doing profiling builds. Perhaps it would be more correct to name them devel-prof or something or one day hopefully move to shared profiling libraries. "-prof" subpackages are mentioned in https://fedoraproject.org/wiki/Packaging:Haskell > > > 2) There shouldn't be common_summary, common_description, and ghc_pkg_c_deps > > > macros since these are only used once. The ghc_pkg_deps line should be removed > > > completely because the macro is undefined. > > > > These are also standard Haskell packaging things. I think the %{common_*} > > macros are used in the %{?ghc_lib_package} line which is where the -prof and > > -devel subpackages are defined. > > I don't see any reference to this on the Haskell packaging guidelines page: > > http://fedoraproject.org/wiki/Packaging/Haskell I have been slowly revising the guidelines, which have become out of date: https://fedoraproject.org/wiki/PackagingDrafts/Haskell and hope to submit them for RFC and review soon. The macros defined in ghc-rpm-macros really help to simplify Haskell packaging and avoid having to keep close to 100 packages now in sync with latest evolving packaging (that will soon be close to 300 .spec files). (In reply to comment #5) > I also don't see a %files section. Is that somehow included by > %{?ghc_lib_package}? That's correct: the macros handle the repetitive steps of build, install and filelist generation, since they are essentially the same for all haskell package built with Cabal.
It took longer than I had hoped but last week the revised draft was posted to the Fedora packaging and haskell-devel lists.
Note that with ghc-rpm-macros in f16 rawhide, prof subpackages are no longer generated so this takes care of comment 6.
This is how the package would look without %ghc_lib_package: http://petersen.fedorapeople.org/ghc-pcre-light/ghc-pcre-light.spec I also put up the srpm if someone wants to try to build it http://petersen.fedorapeople.org/ghc-pcre-light/ghc-pcre-light-0.4-1.fc14.src.rpm
(In reply to comment #12) > http://petersen.fedorapeople.org/ghc-pcre-light/ghc-pcre-light-0.4-1.fc14.src.rpm Oops that was the old package I meant: http://petersen.fedorapeople.org/ghc-pcre-light/ghc-pcre-light-0.4-2.fc15.src.rpm
Ok this review has been stalled for quite a while. I will submit a new review shortly and close this one as a duplicate.
*** This bug has been marked as a duplicate of bug 713361 ***