D16593: [ExtractorCollection] Use only best matching extractor plugin

[Stefan Brüns]

bruns added a comment.


  In D16593#354311 <https://phabricator.kde.org/D16593#354311>, @bcooksley wrote:
  
  > As noted in the build log on the CI system, kfilemetadata doesn't depend on kcoreaddons so you therefore cannot rely on the kde5.xml file being available:
  >
  >   [kf5-qt5 SUSEQt5.9] Running shell script
  >    + python3 -u ci-tooling/helpers/prepare-dependencies.py --product Frameworks --project kfilemetadata --branchGroup kf5-qt5 --environment production --platform SUSEQt5.9 --installTo /home/jenkins//install-prefix/
  >    Retrieving: Frameworks-extra-cmake-modules-kf5-qt5
  >    Retrieving: Frameworks-ki18n-kf5-qt5
  >    Retrieving: Frameworks-karchive-kf5-qt5
  >
  > The CI system is working correctly in this case and as designed, only allowing actual dependencies of a project to be used during it's build and testing.
  
  
  Obviously the tests require a sufficient dataset for a working QMimeDatabase. This hasn't changed, only the extent of required mime types has. Up until now, the implicitly installed definitions (shared-mime-info?) did the job.
  
  So, which mime-types are guaranteed by the CI system to be available? Can one rely on shared-mime-info? What about Windows/macOS?
  
  There are dozens of mime types in shared-mime-info which are sub-class-of application/xml, see:
  `grep -E 'mime-type |sub-class-of.*application/xml'  /usr/share/mime/packages/freedesktop.org.xml | grep -B1 sub-class-of | head `

REPOSITORY
  R286 KFileMetaData

REVISION DETAIL
  https://phabricator.kde.org/D16593

To: bruns, #frameworks, astippich
Cc: bcooksley, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181105/ff51397e/attachment-0001.html>