Red Hat Bugzilla – Bug 188019
kdelibs: --enable-inotify (--disable-libfam)
Last modified: 2007-11-30 17:11:29 EST
You may recall, on the kde-packagers list awhile, it was (strongly) suggested
that enabling kdelibs native inotify support is much preferred than relying on
I tried this, and it worked to enable kdelibs' inotify support (though I haven't
had a chance to test out how well it works yet).
and before %configure:
export CPPFLAGS="$CPPFLAGS -I$(find /usr/src/kernels/*/include/linux/inotify.h
-print | sed -e 's|linux/inotify.h||' | head -1 )"
And of course, and do
%configure --enable-inotify --disable-libfam
The old version of gamin does not have inotify back-end but the new one in FC5
has already this feature. I don't see the necessity to disable gamin.
Did you not read the same kde-packagers list?
"--enable-inotify is default if you have recent enough kernel headers.
What you would want instead is --disable-libfam - especially if you're sure
you will have gamin and not the real fam. gamin has exactly 0 advantage
over the builtin implementation."
Besides, what about FC-4?
See also bug #192959 (glibc-kernheaders: include inotify.h)
Don't care about FC-4 anymore, eh? (:
i have talked with gamin upstream maintainer and he does not object the dropping
gamin in kdelibs. So i will enable it after the bug #192959 is fixed!
I can do that, do we still need dnotify when we already have inotify? I'd
throw that out and replace it with --enable-inotify and --disable-libfam.
It should also work with glibc-kernheaders (without kernel-devel) now,
although inotify headers seems to cause problems on ia64 for me...
Oookey, seems that inotify fixed itself on ia64 in the meantime, at least
dovecot passed again, so i will go ahead as soon as i have some ACK
regarding removal of "--enable-dnotify" that's currently in the configure
Hmm, i have just checked for myself,
kio/kio/kdirwatch.cpp, 287 supports_dnotify = !supports_inotify;
so i keep in both, it should do no harm and should make KDE work better
with older kernels... Not that we have any, but anyway.