From owner-freebsd-x11@FreeBSD.ORG Sat Dec 1 17:21:37 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 6DFD316A421 for ; Sat, 1 Dec 2007 17:21:37 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB1F13C4EF for ; Sat, 1 Dec 2007 17:21:36 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA01.westchester.pa.mail.comcast.net with comcast id KQyh1Y00C1HzFnQ050J100; Sat, 01 Dec 2007 17:21:36 +0000 Received: from discordia ([24.60.136.97]) by OMTA14.westchester.pa.mail.comcast.net with comcast id KVMb1Y00N26FYqY0300000; Sat, 01 Dec 2007 17:21:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=ToCcFi4Oe0qho-mXygcA:9 a=1iVrt8d45i0DjUjRQ-oA:7 a=HhWi2j0JR1oXn9g0c1-QmtRuXLcA:4 a=CiSHi91Bn78A:10 a=DaesBejaU44A:10 a=6bqG61NMjcsA:10 Received: by discordia (Postfix, from userid 103) id 97E761634F6; Sat, 1 Dec 2007 12:21:35 -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 6B8E71634F6; Sat, 1 Dec 2007 12:21:19 -0500 (EST) Message-ID: <475197F8.70103@FreeBSD.org> Date: Sat, 01 Dec 2007 12:20:56 -0500 From: Coleman Kane Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: cokane@FreeBSD.org References: <200712011015.58979.antik@bsd.ee> <4751248C.4040500@gmail.com> <200712011748.17573.antik@bsd.ee> <475195E2.9060903@FreeBSD.org> In-Reply-To: <475195E2.9060903@FreeBSD.org> 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:21:37 -0000 Coleman Kane wrote: > 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 > I forgot to mention that "git-checkout" is the command you'd use to switch between branches "cvs" and "master", rather than "git-branch". The latter simply manages branches in the db. -- Coleman Kane