Hi, I've noticed that update-mime-database is not run for /usr/kde/4.{1,2}/share/mime, which is the mime dir when kde is built with kdeprefix use-flag set. The ebuild calls fdo-mime_mime_database_update from fdo-mime.eclass, but this command hardcodes mime path to /usr/share/mime. One symptom of this problem is that java applets do not work in konqueror until you run update-mime-database /usr/kde/4.{1,2}/share/mime - see [1] Regards, Matěj [1] https://bugs.kde.org/show_bug.cgi?id=161825
How about symlink between /usr/kde/4.X/share/mime and /usr/share/mime. That should work right?
(In reply to comment #1) > How about symlink between /usr/kde/4.X/share/mime and /usr/share/mime. > That should work right? > I don't think so - as kde 4.1 and 4.2 install slightly different mime packages here, potentially interfering with each other. So symlinking before installation is not really a solution. I don't think the problem is that the mimo info is in separate dir, as it's just some kde-specific stuff. My proposed solution is to extend fdo-mime eclass to allow updating custom directories.
In that case making it use XDG_DATA_DIRS as a reference would probably be a good idea.
scarab I agree with Matěj... and if a directory like that exists on upstream (I meant if upstream devs want to install mime in this dir) I suppose there is a good reason... :) idea for XDG_DATA_DIRS looks good, for example : XDG_DATA_DIRS=${XDG_DATA_DIRS:-${ROOT}/usr/share/mime} fdo-mime_mime_database_update() { if [ -x "/usr/bin/update-mime-database" ] then einfo "Updating shared mime info database ..." "/usr/bin/update-mime-database" "${XDG_DATA_DIRS}" fi } something like that...
Resolving since kdeprefix is use-masked and will go away.
It may rot, but let's not shuffle it under the carpet.
kdeprefix is going away. Now really.
