Hide Forgot
Description of problem: libextractor sources contain two pdf reader plugins - one based on embedded copy of xpdf code (plugins/pdf/pdfextractor.cc) and (as of 0.5.12) own minimal pdf extractor sufficient to read meta-data out or the pdf (plugins/pdfextractor.c). pdfextractor.c seems to be a default pdf extractor in current libextractor versions, unless overridden at compile time by --enable-xpdf as is done in Fedora packages. As xpdf code is frequently patched for security issues that may (or may not) affect libextractor. Please consider using default pdf extractor unless there is a well-known reason why xpdf-based version should be used. As a side effects, using minimal pdfextractor.c may allow you to merge -pdf subpackage to -base, as it is written in C and hence does not require extra libs (C++ libs) needed by xpdf-based version (which is probably a reason for separate subpackage). Version-Release number of selected component (if applicable): libextractor-0.5.20b-1
should be solved since 0.5.22-1
Thank you. Anyway, configure log related to xpdf support is rather amusing: with --disable-xpdf: configure: NOTICE: xpdf disabled (result: limited PDF support) with --enable-xpdf: configure: NOTICE: xpdf enabled (xpdf has a bad security record) Enrico, have you considered -pdf sub-package to -base as proposed above? -pdf no longer has any extra dependencies compared to -base, which, I guess, was the main reason for separate -pdf sub-package.
Needinfo on the -pdf sub-package merge.