From owner-freebsd-ports@FreeBSD.ORG Mon Apr 14 09:13:58 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 CCCA91065670 for ; Mon, 14 Apr 2008 09:13:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 531FA8FC13 for ; Mon, 14 Apr 2008 09:13:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 212B6A1E6D for ; Mon, 14 Apr 2008 10:50:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 15CAAA1E73 for ; Mon, 14 Apr 2008 10:50:11 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E2A72A1E6E for ; Mon, 14 Apr 2008 10:50:10 +0200 (CEST) Received: from wep4017.physik.uni-wuerzburg.de ([132.187.37.17]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.1) with ESMTP id 2008041410500952-2070 ; Mon, 14 Apr 2008 10:50:09 +0200 Received: by wep4017.physik.uni-wuerzburg.de (sSMTP sendmail emulation); Mon, 14 Apr 2008 10:50:09 +0200 From: "Alexey Shuvaev" Date: Mon, 14 Apr 2008 10:50:09 +0200 To: ports@freebsd.org Message-ID: <20080414085009.GA884@wep4017.physik.uni-wuerzburg.de> References: <200804082143.06208.mi+mill@aldan.algebra.com> <1207707476.17121.53.camel@shumai.marcuscom.com> <20080413155908.GB23437@tirith.brixandersen.dk> MIME-Version: 1.0 In-Reply-To: <20080413155908.GB23437@tirith.brixandersen.dk> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.17 (2007-11-01) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.1|February 07, 2008) at 04/14/2008 10:50:09 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.1|February 07, 2008) at 04/14/2008 10:50:10 AM, Serialize complete at 04/14/2008 10:50:10 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=gio X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: 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: Mon, 14 Apr 2008 09:13:58 -0000 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.