From owner-freebsd-x11@FreeBSD.ORG Sat Dec 1 17:12:43 2007 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7D2116A41A for ; Sat, 1 Dec 2007 17:12:43 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9512F13C46A for ; Sat, 1 Dec 2007 17:12:43 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id KUJQ1Y00816AWCU0A05Q00; Sat, 01 Dec 2007 17:12:47 +0000 Received: from discordia ([24.60.136.97]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id KVCm1Y00126FYqY0800000; Sat, 01 Dec 2007 17:12:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=tIPX-fXp3QloxumMLCAA:9 a=Eh9Uuo-lWot_JIFTZWcA:7 a=RhGovpTUoyP6L0nsLw-iss5Ty4EA:4 a=CiSHi91Bn78A:10 a=DaesBejaU44A:10 a=kJVaTwQnZmMA:10 Received: by discordia (Postfix, from userid 103) id 5BC5F1634F6; Sat, 1 Dec 2007 12:12:41 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id DC5711634F6; Sat, 1 Dec 2007 12:12:24 -0500 (EST) Message-ID: <475195E2.9060903@FreeBSD.org> Date: Sat, 01 Dec 2007 12:12:02 -0500 From: Coleman Kane Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Andrei Kolu References: <200712011015.58979.antik@bsd.ee> <4751248C.4040500@gmail.com> <200712011748.17573.antik@bsd.ee> In-Reply-To: <200712011748.17573.antik@bsd.ee> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org Subject: Re: Xorg meta ports bloated dependencies X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@FreeBSD.org List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2007 17:12:43 -0000 Andrei Kolu wrote: > Saturday 01 December 2007 11:08:28 kirjutas Yuri Pankov: > >> Andrei Kolu wrote: >> >>> Saturday 01 December 2007 05:20:40 kirjutas dexterclarke@safe-mail.net: >>> >>>> I've just been helping somebody through an installation of >>>> 6.2-RELEASE and we've noticed the excessive dependencies of >>>> the xorg meta ports. >>>> >>>> xorg-server 1.4, for example, depends on: >>>> >>>> dbus-1.0.2_2, dbus-glib-0.74, glib-2.14.2, gnome_subr-1.0, >>>> hal-0.5.8.20070909 and even strange things like cdrtools-2.01_6. >>>> >>>> xorg-server 1.2 (the one distributed with the 6.2-RELEASE CD) >>>> doesn't have these dependencies. >>>> >>>> Putting it bluntly: why is this crap being dragged in? Neither >>>> of us use GNOME or anything that might require dbus. I can't see >>>> why xorg-server could possibly need any of the above? >>>> >>>> Anxiously awaiting a flaming argument. >>>> >>> And why xorg should include ugly fonts like adobe* an type1*? >>> >> Because it IS a *META* port and should install everything that is part >> of xorg distribution? You are free to install the ports that you need, >> use WITHOUT_HAL for xorg-server, etc. And there are many people who >> think that ttf fonts are ugly, and bitmap and type1 fonts are more >> readable. >> >> > I'd like to see choices in metaport- ncurses based menus with packages we > really need. It is impossible to install Xorg without metaport (anyone have > done that at all?)- 300+ separate ports IIRC. After removing unnecessary > ports (fonts FE) and later you may try to upgrade Xorg to newer version then > package dependency would be broken... > > Or how can I tell metaport how to NOT INSTALL some crap I don't need. > > Andrei > > I think you are mistaken in your understanding of the metaport. It is not there to offer up a bunch of options on how to install X.org. Rather, it is so that someone (like myself) can install the most common X.org deployment without worrying about that they might be missing some important components (like xterm, xload, or xclock) that aren't actual dependencies of any part of the X.org core. As I can see from here, you may also not be recognizing that various parts of hal-enabled X.org do actually depend upon things like glib. Perhaps it might come as a surprise that a growing number of non-GNOME apps use glib for a decent cross-platform runtime library! Glib is not "part of GNOME", rather it is a dependency of GNOME, as well as other apps that decided to use it as their runtime, rather than implementing numerous platform-specific variants of threading, unicode, random number access, data structures in C, and other useful tools. If you actually read through the Makefiles, you can get the toggles that turn on/off functionality. You can then stick these toggles into /etc/make.conf and they will apply to all future builds. For example, if you don't want dbus-*, glib-*, etc... dependencies (which are hal dependencies, which is at line 42 of the xorg-server Makefile), then you should be able to add WITHOUT_HAL=yes to /etc/make.conf. You can always add any of these options to make.conf and they will always be applied to the port(s) you are trying to build. It is easy, just read the docs. If you have an issue with various dependencies for which you don't get a choice to disable via a command-line make argument, why don't you submit a patch? I am sure that the port maintainer would be happy to review it. If you have a better idea of a leaner meta-port that would be a good solution for everyone, feel free to propose it. I don't see any reason why we can't implement an x11/xorg-lite port, if someone is willing to take the time to maintain it. In fact, if you spend a little time to parse the Makefiles, you can grep for _DEPEND and get a list of the things that they depend upon. You can still edit these by hand. You can even maintain a ports tree for yourself using git or a similar revision-control system, which should allow you to merge in changes from HEAD without trashing some local modifications that you have done yourself (or at least minimizing the amount of manual work that needs to be done). You could keep your ports managed in the "master" branch and create a "cvs" branch or similar using git-branch. Switch to that branch when you run cvsup, then use git-add/git-commit to apply cvsup's changes into git. Then you would switch back to "master" and merge those changes in from the "cvs" branch. Ideally, you won't have to manually edit any files unless some really huge change comes along. -- Coleman Kane