Date: Sat, 01 Dec 2007 12:20:56 -0500 From: Coleman Kane <cokane@FreeBSD.org> To: cokane@FreeBSD.org Cc: freebsd-x11@freebsd.org Subject: Re: Xorg meta ports bloated dependencies Message-ID: <475197F8.70103@FreeBSD.org> In-Reply-To: <475195E2.9060903@FreeBSD.org> References: <N1-sUXCn9R-0s@Safe-mail.net> <200712011015.58979.antik@bsd.ee> <4751248C.4040500@gmail.com> <200712011748.17573.antik@bsd.ee> <475195E2.9060903@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?475197F8.70103>