On Tue, 15 Apr 2008 02:38:48 -0500, Alexey Shuvaev
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
wrote:
On Mon, 14 Apr 2008 03:50:09 -0500, Alexey Shuvaev
<[EMAIL PROTECTED]> 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.
--
[EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED]
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
