From owner-freebsd-ports@FreeBSD.ORG Tue Apr 15 16:44:26 2008 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F1CF106564A for ; Tue, 15 Apr 2008 16:44:26 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtao106.cox.net (eastrmmtao106.cox.net [68.230.240.48]) by mx1.freebsd.org (Postfix) with ESMTP id EAAA28FC17 for ; Tue, 15 Apr 2008 16:44:25 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080415164415.EQKH15722.eastrmmtao106.cox.net@eastrmimpo02.cox.net>; Tue, 15 Apr 2008 12:44:15 -0400 Received: from mezz.mezzweb.com ([24.255.149.218]) by eastrmimpo02.cox.net with bizsmtp id DskQ1Z00C4iy4EG02skQRt; Tue, 15 Apr 2008 12:44:24 -0400 Date: Tue, 15 Apr 2008 11:46:26 -0500 To: "Alexey Shuvaev" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <200804082143.06208.mi+mill@aldan.algebra.com> <1207707476.17121.53.camel@shumai.marcuscom.com> <20080413155908.GB23437@tirith.brixandersen.dk> <20080414085009.GA884@wep4017.physik.uni-wuerzburg.de> <20080415073848.GA802@wep4017.physik.uni-wuerzburg.de> Content-Transfer-Encoding: Quoted-Printable Message-ID: In-Reply-To: <20080415073848.GA802@wep4017.physik.uni-wuerzburg.de> User-Agent: Opera Mail/9.27 (Linux) Cc: ports@freebsd.org Subject: Re: what is gio-fam? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 16:44:26 -0000 On Tue, 15 Apr 2008 02:38:48 -0500, Alexey Shuvaev = wrote: > On Mon, Apr 14, 2008 at 10:31:18AM -0500, Jeremy Messenger wrote: >> On Mon, 14 Apr 2008 10:09:06 -0500, Jeremy Messenger = = >> wrote: >> >>> On Mon, 14 Apr 2008 03:50:09 -0500, Alexey Shuvaev >>> wrote: >>> >>> >>>> IMHO gio-fam-backend should not be implicit dependency. Otherwise w= hy >>>> not to install all existing non-conflicting libraries just to ease >>>> maintainer's life :-> >>>> FWIW x11-toolkits/gtkdatabox2 (PR 116120) do not need gio-fam-backe= nd. >>> >>> Well, all ports should depend on gio-fam-backend. The gio is include= d = >>> and >>> part of glib20. marcus had to split gio out of glib20 package to avo= id >>> circle dependency of glib20 -> gamin (FAM replacement) -> glib20. If= >>> marcus doesn't split and you guys will have that gio library anyway.= > > Thanks, somewhat much clearer now. I had some feeling that = > gio-fam-backend is > freebsd specific. > How many chances are there to account for existence of gamin upstream?= > (So to avoid glib -> gamin -> glib circular dependency) I had chat with marcus (included my team) to get more clear info for us.= = He said: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Here's the deal. Glib 2.16 includes a lot of the file management code that was previously included in gnome-vfs. Part of that code is a file monitor wrapper which allows the new GIO subsystem to get real-time file update information. This wrapper has FAM, inotify, and Solaris backends. The only backend that works on FreeBSD is the FAM backend. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D If anyone is still complaining, then anyone can implement a GIO monitor = = using pure kqueue. This will get glib20 to not depend on FAM anymore. It= = can be take a lot of code from gamin. marcus has said a bit more: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Since we couldn't have glib depend on FAM directly, I broke out this file monitor module into a separate port. Any port which depends on glib could use the GIO subsystem, and would need one of these file monitor modules to be fully functional. I thought it would be easier to just make ports that depend on glib20 automatically require this module so maintainers wouldn't have to check and see if their port used GIO. Fam/gamin are not big dependencies. Hell, they don't even take up memory unless used. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Keep in mind, in the next major release of GTK+ depends on GIO. It's = already in GTK+ SVN for depend on GIO, so it won't make any difference. >> Uh, I should have check in glib20 and gio-fam-backend before I made t= hat >> comment. I thought that gio (libgio-2.0.so) is in gio-fam-backend, bu= t = >> not >> it's in glib20. The gio-fam-backend only installs libgiofam.so and FA= M >> support is option in glib configure. I don't think it will be easy to= = >> make >> optional (maybe I am wrong) with that split. Remove gio-fam-backend >> dependency is going to hurt some users if they want some missing = >> fuction(s) >> of it. >> > > So configure option is not enough. Nevermind about above for not think will be easy. I have taken a look mo= re = in gio-fam-backend and figured out to make optional. I am still discussi= ng = with my team (some disagree and agree), because make it optional will = causing some reduced functionality in runtime. I am thinking about add = something like WITHOUT_FAM_WARNING with better explain and users will kn= ow = their choice to have functions reduced, so can't be report to us. IMO, I do still think add optional is a bit silly since GIO basicually = already have similar function of gamin. It's just happen that there is n= o = kqueue backend available for FreeBSD and forced us to get glib20 depends= = on FAM or gamin. I am kind of on fence to make it optional. > Does separating gio-fam-backend by original developers solve the > problem better? I think marcus's comments have answered to this. Cheers, Mezz > Alexey. -- = mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org