Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Apr 2008 11:46:26 -0500
From:      "Jeremy Messenger" <mezz7@cox.net>
To:        "Alexey Shuvaev" <shuvaev@physik.uni-wuerzburg.de>
Cc:        ports@freebsd.org
Subject:   Re: what is gio-fam?
Message-ID:  <op.t9nvjolo9aq2h7@mezz.mezzweb.com>
In-Reply-To: <20080415073848.GA802@wep4017.physik.uni-wuerzburg.de>
References:  <200804082143.06208.mi%2Bmill@aldan.algebra.com> <1207707476.17121.53.camel@shumai.marcuscom.com> <20080413155908.GB23437@tirith.brixandersen.dk> <20080414085009.GA884@wep4017.physik.uni-wuerzburg.de> <op.t9lwdgr99aq2h7@mezz.mezzweb.com> <op.t9lxegs69aq2h7@mezz.mezzweb.com> <20080415073848.GA802@wep4017.physik.uni-wuerzburg.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Apr 2008 02:38:48 -0500, Alexey Shuvaev  =

<shuvaev@physik.uni-wuerzburg.de> 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 <mezz7@cox.net> =
 =

>> wrote:
>>
>>> On Mon, 14 Apr 2008 03:50:09 -0500, Alexey Shuvaev
>>> <shuvaev@physik.uni-wuerzburg.de> wrote:
>>>
>>> <snip>
>>>> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.t9nvjolo9aq2h7>