https://bugzilla.redhat.com/show_bug.cgi?id=1069257 --- Comment #30 from Michael Schwendt <bugs.michael@xxxxxxx> --- Hmmm... I'm not so sure anymore whether it has been a good idea to approve the package. The attached patch is just an example of a basic framework to get started. It does not use all source files from the fparser-4.5.1.zip archive. For example, if you wanted to add the optional gmp/mpfr features, the patch would need to be adjusted to compile the extra sources into the library *and* install the extra headers, too. That's a big of a chicken'n'egg problem. Once you decide on which features to include in the library, they cannot simply be turned on/off in the same way as when using fparser as a copylib (with modifications to fpconfig.hh possibly). Oh, and after a second look, only the header file fparser.hh is needed in the fparser-devel package. fpaux.hh, fptypes.h and fpconfig.h are internal to the lib and not included by fparser.hh. > I wasn't sure whether to include the autotools files or only the generated files. Regenerating them at the end of %prep (not the start of %build) is fine. The topic of including pregenerated files as a patch is more relevant to large projects where upstream maintains the autotools files, macros and makefiles. > Since we maintain the autotools files ourselves, we shouldn't get > into trouble with incompatible autotools versions. And as a last resort, it would be possible to fix the files and build a pregenerated tarball based on "make dist". -- 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://admin.fedoraproject.org/mailman/listinfo/package-review