https://bugzilla.redhat.com/show_bug.cgi?id=819264 --- Comment #13 from pcpa <paulo.cesar.pereira.de.andrade@xxxxxxxxx> --- It is going to require significant rework I guess, as well as in libfac. Maybe the proper approach should be to have the Singular package generate libfac and libfac-devel, given that libfac sources are from singular upstream repository... I will need to patch configure.in files and autoreconf to comment AC_PROG_CC and leave only AC_PROG_CXX and probably a few other changes, or it will fail to "detect" factor.h due to not finding C++ stuff as it tries to compile the test program with gcc. libfac-devel probably should also generate a plain /usr/lib64/libsingfac.a and not only /usr/lib64/libsingfac_g.a, but I am afraid there may be issues with the build conditionals, e.g. if test "x$with_Singular" = xyes; then libfactory=libsingcf.a [...] else libfactory=libcf.a [..] fi Maybe the singular package should provide libfac and libfac-devel as a subpackage. Also, libfac-devel version does not exactly match the one in the Singular review request, libfac-devel is: http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/Libfac/libfac-3-1-1.tar.gz but to match this review request, it should be: http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/Libfac/libfac-3-1-3.tar.gz Also, Maybe factory should be built separately, or, again, be a subpackage of Singular, e.g. contents of http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/Factory/ The singular package in the review request does not install any .a library, but it builds: $ find BUILD/Singular-3-1-3/ -name \*.a BUILD/Singular-3-1-3/factory/libsingcf.a BUILD/Singular-3-1-3/factory/libsingcf_g.a BUILD/Singular-3-1-3/omalloc/libomalloc.a BUILD/Singular-3-1-3/omalloc/libomalloc_ndebug.a BUILD/Singular-3-1-3/libfac/libsingfac_g.a BUILD/Singular-3-1-3/libfac/libsingfac.a BUILD/Singular-3-1-3/kernel/libkernel_g.a BUILD/Singular-3-1-3/kernel/libkernel.a and libfac-devel installs: $ rpm -ql libfac-devel /usr/include/factor.h /usr/lib64/libfac.a /usr/lib64/libsingfac_g.a /usr/share/doc/libfac-devel-3.1.1 /usr/share/doc/libfac-devel-3.1.1/00README /usr/share/doc/libfac-devel-3.1.1/COPYING /usr/share/doc/libfac-devel-3.1.1/ChangeLog So, if the singular package would provide libfac-devel as a subpackage, it would also need to do two builds, that is, one $with_Singular unset, so that it would generate libfac.a instead of libsingfac.a. Does this qualify as a reason for an exemption and special case? I mean, Singular was also built in a specific, not latest, version because the api is somewhat unstable, and this is the version that works with sagemath. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review