Xorg meta ports bloated dependencies
cokane at FreeBSD.org
Sat Dec 1 09:12:43 PST 2007
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 at 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
> 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.
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
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.
More information about the freebsd-x11