Xorg meta ports bloated dependencies

[Coleman Kane]

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 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
>>> 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