On Sun, Apr 13, 2008 at 05:59:09PM +0200, Henrik Brix Andersen wrote:
> On Tue, Apr 08, 2008 at 10:17:56PM -0400, Joe Marcus Clarke wrote:
> > gio-fam-backend is a new piece of glib which provides a wrapper around
> > FAM to allow applications to monitor file objects using a glib API.
>
> But this is optional, right? Any reason for making gio-fam-backend an
> implicit dependency for all software, that depends on glib20?
>
> On my systems, this means I will get gio-fam-backend installed even
> though I don't have FAM installed at all.
>
Hello!
Just another vote against gio-fam-backend. I had have a quick look at
mailing lists archives and hadn't found any discussion about it
prior to commit. The point is thas gtk != gnome. Even more so glib != gnome.
Introducing gio-fam-backend as a dependency to glib automatically adds
it to the dependency lists of too many other (not gnome related) ports.
Personally I don't use neither gnome nor kde but I use gtk apps (gqview, gimp,
beep-media-player, mplayer, seamonkey, ...) and for now I have no FAM system
installed and I don't want any at all. I had some experience with FAM some
time ago when it was non-optional requirement for samba. Since then I don't
like FAM systems due to their 'viral' nature: many ports will auto-detect
and uncoditionally link with them. Sweeping FAM out of the system after
that is not straightforward process.
Another aspect is that FAM is not so critical for most apps (I believe).
With samba it is clear: samba wants to monitor its conf files
in order to apply changes immediately.
And what is the use of FAM for typical gui-user-application?
Any example of such app that really will not properly function without
gio-fam-backend?
(Well, I am sure there are such and gio-fam-backend
was made a dependency for glib not just for fun. But some examples
would not hurt anyone.)
Joe Marcus Clarke at Mon Mar 24 20:27:23 PDT 2008:
> Glib 2.16 (with GIO) was designed to support pluggable file monitor
> backends. Without one such backend, any libgio consumer would be
> severely handicapped. The only reason gio-fam-backend is broken out
> as a separate port is that we have one FAM provider that requires glib.
> If this was not the case, we'd just have glib20 depend on FAM.
^^^
why glib?
> Recompiling alone is not sufficient. Ports will happily build
> without this backend, but may not run correctly if they require libgio.
> The cost of the FAM dependency
> is minimal (most GNOME apps already had this as part of gnome-vfs),
^^^ ^^^ ^^^
Well, gnome-vfs can really need FAM support. But then why not to add
gio-fam-backend as a dependency to gnome-vfs instead of glib?
If I understand things correctly one can install gio-fam-backend (which is
pluggable module) at any point provided glib is already installed. So moving
gio from glib to gnome-vfs will not only make gio-fam-backend more gnome
specific but also possibly remove the hack with _glib20.
> and it just makes things easier for developers not to have
> to worry about adding the gio-fam-backend dependency.
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.
Just my 0.02$,
Alexey.