Looking to Strigi, it looks like the same as done in glib-2 (bug 413403) applies for it: it's much better to directly rely on direct inotify support on linux than using obsolete and dead fam/gamin. Then, I would suggest to enable inotify support by default and use.mask "fam" at default/linux/package.use.mask as done with glib-2 to make people use inotify instead of using it indirectly via gamin (this is also the way used in Arch Linux for ages without issues) Thanks
I guess we should probably do something similar for kde-base/kdelibs and kde-frameworks/kcoreaddons too?
Thanks, fixed in git. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4e4ad4e26c19bccb91426290a726ce6fec4d3167 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d18e5f2b0bf52f3cb45c9005fed38820945fd164
(In reply to Michael Palimaka (kensington) from comment #1) > I guess we should probably do something similar for kde-base/kdelibs and > kde-frameworks/kcoreaddons too? At least for the KF5 package kcoreaddons Arch Linux (who as mentioned before disable FAM in kdelibs and strig) don't disable it and have it listed in their dependencies (https://projects.archlinux.org/svntogit/packages.git/plain/kcoreaddons/trunk/PKGBUILD). The CMakeLists.txt of kcoreaddons also mentions additional features when building with FAM support: PURPOSE "Provides file alteration notification facilities using a separate service. FAM provides additional support for NFS." But I'm not sure if this is still true, especially since the code is pretty old and probably copied over from kdelibs (as stated in the header of kdirwatch.cpp). I'm not really familiar with either FAM or NFS.
(In reply to Timo Gurr from comment #3) [...] > PURPOSE "Provides file alteration notification facilities using a separate > service. FAM provides additional support for NFS." > I think that for that NFS capabilities even the original fam was needed over gamin and, then, the virtual wouldn't comply that
