what is gio-fam?

[Jeremy Messenger]

On Tue, 15 Apr 2008 02:38:48 -0500, Alexey Shuvaev  
<shuvaev at 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 at cox.net>  
>> wrote:
>>
>>> On Mon, 14 Apr 2008 03:50:09 -0500, Alexey Shuvaev
>>> <shuvaev at physik.uni-wuerzburg.de> wrote:
>>>
>>> <snip>
>>>> IMHO gio-fam-backend should not be implicit dependency. Otherwise why
>>>> 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-backend.
>>>
>>> Well, all ports should depend on gio-fam-backend. The gio is included  
>>> and
>>> part of glib20. marcus had to split gio out of glib20 package to avoid
>>> 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:

====================================================
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.
====================================================

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:
====================================================
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.
====================================================

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 that
>> comment. I thought that gio (libgio-2.0.so) is in gio-fam-backend, but  
>> not
>> it's in glib20. The gio-fam-backend only installs libgiofam.so and FAM
>> 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 more  
in gio-fam-backend and figured out to make optional. I am still discussing  
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 know  
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 no  
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 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org