https://bugzilla.redhat.com/show_bug.cgi?id=1369708 --- Comment #13 from Ralf Corsepius <rc040203@xxxxxxxxxx> --- (In reply to yunying.sun from comment #12) > Could you help to review again? Here we go: - Please append --disable-silent-rules to %configure This enforces verbose building, because silent building is not helpful when building packages in batches. - Please disable-static libs. Static libs are strongly discouraged in Fedora. To achieve this, append --disable-static to %configure and remove %{_libdir}/*.a from %files - Please add LICENSE to %license in %files: %files ... %license LICENSE - Consider to add README.md and ChangeLog to %doc %files ... %doc README.md ChangeLog - *-devel should Requires: %{name}%{?_isa} = %{version}-%{release} not Requires: %{name} = %{version}-%{release} - Directories %{_includedir}/sapi and %{_includedir}/tcti should be owned. Please change %{_includedir}/sapi/*.h %{_includedir}/tcti/*.h into %{_includedir}/sapi %{_includedir}/tcti I am going to attach a patch proposal comprising all changes up to here to this BZ. - IMHO, the CFLAGS in upstream's *.pc.ins are bogus. They all contain Cflags: -I@includedir@/<subpkg> while I think they should contain Cflags: -I@includedir@ What actually is correct, depends upon which form of #include statements upstream expects consumers/users of these libs to use: If they are expected to use "#include <someheader.h>" then the 1st form would be correct. If they are expected to use "#include <subpkg/someheader.h>" then the 2nd form would be correct. In general, the 2nd form is better, because the 1st form is more likely to erroniously pickup bogus headers from the compiler's include path. Finally, one general (upstream-related) question: On which architectures/target-platform is this package useful on/applicable to? I guess, it's probably x86_64 + i686 only (or x86_64 only?), but not on others (arm, sparc, s3**, ppc, ...). -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx