GNOME Bugzilla – Bug 530635
circular depency between GIO (fam-helper) and gamin (as a FAM provider)
Last modified: 2018-07-01 08:48:04 UTC
GIO provides file alteration monitoring support via the FAM API, basically as an optional fallback for linux and seemingly the only way to have file alteration monitoring support on other kind of kernels. Out of the FAM API providers the most sane and popular API provider is gamin. However gamin itself depends on glib, introducing a circular dependency that makes bootstrapping glib/gio with fam support impossible unless glib is built twice. Passing this to GIO right now, as that's what introduced the circular dependency. Maybe something needs to be done to gamin instead, like a package split-up between libgamin and gam_server, but that's icky as well.
Forgot the downstream bug link: https://bugs.gentoo.org/show_bug.cgi?id=217861
Ping? This bug is going to hurt some of our users. Thanks
Not much that we can do about this. Building glib twice is not the end of the world, building OpenOffice twice is much worse...
It's a clean bootstrap issue that is somewhat mitigated for binary distributions, as the issue is only exposed at the maintainers side and only if it's a fresh bootstrap for that, but for source distros all users are affected. Anyhow, as there is a possible solution on gamin's side, reassigning to gamin product for a possible split-up of libgamin and gam_server, at least as a clean possibility from configure.in side if not different packages altogether.
The real problem is, that the glib package provides not only one but several separate libraries stacked upon each other. Right now it are glib, gmodule, gthread, gobject and gio. So if you really want to avoid building the glib package several times, split building of it into reasonable pieces. Maybe the configure script should provide support for building glib's libararies separately. A more hackish aproache would be running full configure for each subpackage, and then running sed on the generated to Makefile to patch out some entries from the SUBDIRS variable. Still don't know if this makes any sense, since glib builds rather quickly.
(In reply to comment #5) > Maybe the configure script should provide support for building glib's > libararies separately. A more hackish aproache would be running full configure > for each subpackage, and then running sed on the generated to Makefile to patch > out some entries from the SUBDIRS variable. Still don't know if this makes any > sense, since glib builds rather quickly. > Or maybe the rest of gamin could be ported to GIO (ie, the platforms that are only supported by gamin, if there are any) and make gamin just a compatibility wrapper around gio. 1) Less code aging away in gamin 2) More platform support for GIO Double win :)
w.r.t. #6 If you want to take over gamin and do the work, I'm fine with this. The mission was to develop a FAM workaround. It's hell, it's definitely nothing fun or fancy, but if you want to develop it, sure ! Personally I'm done with it, I will integrate occasional small patches but the ultimate goal of that code is to die (possibly in the least painful way), it's just a workaround between a totally f...d up API and inappropriate kernel support for userland notification. If you like that kind of stuff, please go for it ;-) ! On recent kernel just use inotify directly and forget about FAM, really ! Daniel
Hi Daniel, So are there any missing platforms in GIO compared to gamin? I think we are keeping gamin around just for Gentoo/FreeBSD support. I don't think anyone in the Gnome Herd will miss fam support in gio :) Alex, could you let us know what's GIO's status on non-inotify systems? Thanks
Created attachment 117445 [details] [review] 0001-gam_server-should-use-DAEMON_-instead-of-LIBGAMIN_.patch
Created attachment 117446 [details] [review] 0002-libfam-libgamin-does-not-need-glib.patch
Created attachment 117447 [details] [review] 0003-make-libgamin_shared-a-noinst-libtool-helper-lib.patch
Created attachment 117448 [details] [review] 0004-simplify-python-bindings-installation.patch
Created attachment 117449 [details] [review] 0005-add-configure-switches-to-restrict-building-the-serv.patch
Hi again folks. So here are a bunch of patches. #1 through #3 just clean up some autotools stuff. I've checked the ChangeLog and I know at one point Daniel had tried to make libgamin_shared into a real library. The only missing piece was to make it a libtool library. This basically removes the GLib dependency from libgamin/libfam (which was never real). Patch #4 simplifies the python handling, removing the hand-built rules. Patch #5 is the real stuff, which adds configure switches to build just the server or just libgamin/libfam : - the default setting (when you don't specify anything) is to build everything, just like the current trunk - disabling the library also disables the python bindings - disabling either the library or the server also disables tests A couple notes : - Only autotools files were harmed in those 5 patches - config.h is not included by all .c files, I don't know if it's intended Thanks for considering those patches as it's simpler to split up gamin rather than GLib :) Cheers
Rémi, thanks for the patches. I understand your problem and since patch5 doesn't change the default behaviour, fine by me. I also applied patch 1, 2 and 4 for the associated cleanups, but not patch 3, as it break the 'make dist', by removing the files from libgamin_1_la_SOURCES they don't get included in the tarball anymore, and a build of the result just breaks. I guess they should be added to EXTRA_DIST or just kept in a definition for the shared lib (eg gam_protocol.h) 1, 2, 4 and 5 are commited to SVN Daniel
Created attachment 120945 [details] [review] make-libgamin_shared-a-noinst-libtool-helper-lib.patch Hi Daniel, Thanks for putting those patches in. Here's an updated version of the third patch which applies cleanly on top of the current trunk/ Gamin now passes make distcheck correctly, all was needed was just to add gam_protocol.h back to libgamin_1_la_SOURCES. Thanks again for your help :)
Hi Daniel, I've just noticed you've just released gamin 0.1.10 without one of the patches here. Could you comment on that last patch I attached on Oct 20th (attachment 120945 [details] [review]) and maybe set the "committed" status on the other patches? Thanks
updating patch status.
gamin is not under active development anymore and has not seen code changes for many years. Its codebase has been archived: https://gitlab.gnome.org/Archive/gamin/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.