Xorg and dependency madness

When I install X.org on FreeBSD, I notice that there is a huge number of dependencies, such as Perl and Python2. I know that Xorg's imake depends on Perl and cmake depends on Python.
The issue with this is I have a whole lot of stuff installed for something that, I would imagine, wouldn't depend on all of this. It makes sense that ports would depend on assorted build systems, so maybe I am being silly. I do, of course, want Perl and Python, but it was surprising to me that this stuff wasn't in base. Perl is a very useful language, even, no, especially, on servers.

Anyhow, I want to ask, what is the cause of this proliferation of dependencies, and is there any way it can be circumvented? Also, why doesn't base include common programs like Perl and whatnot?

Maybe base could be split up into sets, the way OpenBSD has done it? OpenBSD is a much smaller project, but they include Perl and Xorg in base, but there are sets in the installer image, so you can pick an choose if you don't want the extras. Is FreeBSD is a much larger project, why hasn't this been done?
 
Perl used to be in the base but turned out to be too much work to maintain and was removed. It's very unlikely that it will come back because of the current policy of minimal base system that should have only the bare essentials and nothing else.
 
If you do not want build dependencies, they can be deleted after applications are built. Or install with binary packages, so no build dependencies are needed.

The problem with adding applications to the base operating system is that they are then frozen to maintain binary compatibility. It means an operating system upgrade is needed to upgrade that application, rather than just upgrading a port or package.
 
If you do not want build dependencies, they can be deleted after applications are built. Or install with binary packages, so no build dependencies are needed.

The problem with adding applications to the base operating system is that they are then frozen to maintain binary compatibility. It means an operating system upgrade is needed to upgrade that application, rather than just upgrading a port or package.

Hmm. I generally prefer ports to packages on FreeBSD, because they are given more emphasis and are more supported, and the opposite for OpenBSD. I like to turn knobs like enabling Motif and Xaw and removing Native Language Support whenever I can.

How do I do that? Can I set it to install all build deps as packages and then delete them? That wouldn't make sense, because many of them will be already there for building something else.

I guess I'll just have to forget about it. Disk space is too cheap, and life so short, to spend much time worrying about these things.
 
Perl used to be in the base but turned out to be too much work to maintain and was removed. It's very unlikely that it will come back because of the current policy of minimal base system that should have only the bare essentials and nothing else.
Hmm, but isn't much development oriented to FreeBSD on servers? In my experience, it's very good at that. But I would imagine many would find Perl useful, especially on servers, such that it would warrent inclusion into base?

Of course, if you're heavily dependent upon Perl, you might be doing something wrong ;).
 
If having build dependencies around really bothers you, you can use ports-mgmt/poudriere in a build jail to build your packages. You'll get both the benefits of port options as well as the ease of use of packages with no build dependency cruft on the host.
 
If having build dependencies around really bothers you, you can use ports-mgmt/poudriere in a build jail to build your packages. You'll get both the benefits of port options as well as the ease of use of packages with no build dependency cruft on the host.
This is an idea, thanks! I could even have a server for doing this, so I build the packages on it and serve them to the other FreeBSD machines.

I wonder, is it possible to have this stuff statically linked. Not seriously, just for shits and giggles.
 
Hmm, but isn't much development oriented to FreeBSD on servers? In my experience, it's very good at that. But I would imagine many would find Perl useful, especially on servers, such that it would warrent inclusion into base?

Of course, if you're heavily dependent upon Perl, you might be doing something wrong ;).
Damn, whenever I type a text emoticon it makes those annoying uppity graphical emoticons that make you look like a 14 year old Ubuntu user. Jesus.
 
Last edited by a moderator:
Hey, John Call,
If you like building things on the cheap. Where Xorg is concerned, have a look at x11/xorg-minimal.
While it still has to suck in build dependencies, the install footprint is a good size smaller, than it's counter version.
Where window managers are concerned, x11-wm/xfce4 is very "Gnome-ish" with less than half the "bloat".

All the best, to you, John Call!

--Chris
 
Last edited by a moderator:
I could never get an x11/xorg-minimal install to work, but this is something for me to figure out. A lot of dependencies have to do with gtk components, like bash, gcc, gtk etc. While, I don't have a problem with those programs, I just wish they'd just be used for programs specific to gnome, linux emulation etc.

With Clang in FreeBSD's base, gcc isn't needed in many cases (when it will build with Clang). Instead of Bash, FreeBSD has its native shell. I've edited a few Makefiles in the jail's port's trees. While doing this, I had to remove all of bash, gtk, gcc and their libraries or the build would fail. Once these were all removed, the compile was done in 5 minutes, instead of 2 hours. Of course, when I took these out, I didn't replace them with the appropriate program in the Makefile, so I expect there to be a lot of missing functionality. Some programs (that required gtk, when gtk dependencies were taken out) worked, but I don't know if this is because Xorg contained gtk. After this, then installing x11/org from packages, I notice that it has a lot of gtk library dependencies.

I believe most ports will go this direction, and clean up the bloated dependencies, replacing them with the FreeBSD licensed equivalents. It's like gtk, bash, and gcc were used out of convenience, since this is how it worked when the programs were first run on linux.

I like to turn knobs like enabling Motif and Xaw
It would be good to replace gtk dependencies with those, if it needed it. I wonder how tr could run through Makefile's and switch these dependencies out.
 
Last edited by a moderator:
Hey, John Call,
If you like building things on the cheap. Where Xorg is concerned, have a look at x11/xorg-minimal.
While it still has to suck in build dependencies, the install footprint is a good size smaller, than it's counter version.
Where window managers are concerned, x11-wm/xfce4 is very "Gnome-ish" with less than half the "bloat".

All the best, to you, John Call!

--Chris
Hmm, I like the ports I get with x11/xorg, like assorted useful X applications, docs, and libraries, to use x11/xorg-minimal.

I have found that xfce4 installs a bunch of gnu dependencies, and I think dbus also. It is light compared to GNOME or KDE, but I usually prefer to use x11-wm/wm2 or similar.
 
Last edited by a moderator:
I could never get an x11/xorg-minimal install to work, but this is something for me to figure out. A lot of dependencies have to do with gtk components, like bash, gcc, gtk etc. While, I don't have a problem with those programs, I just wish they'd just be used for programs specific to gnome, linux emulation etc.

With Clang in FreeBSD's base, gcc isn't needed in many cases (when it will build with Clang). Instead of Bash, FreeBSD has its native shell. I've edited a few Makefiles in the jail's port's trees. While doing this, I had to remove all of bash, gtk, gcc and their libraries or the build would fail. Once these were all removed, the compile was done in 5 minutes, instead of 2 hours. Of course, when I took these out, I didn't replace them with the appropriate program in the Makefile, so I expect there to be a lot of missing functionality. Some programs (that required gtk, when gtk dependencies were taken out) worked, but I don't know if this is because Xorg contained gtk. After this, then installing x11/org from packages, I notice that it has a lot of gtk library dependencies.

I believe most ports will go this direction, and clean up the bloated dependencies, replacing them with the FreeBSD licensed equivalents. It's like gtk, bash, and gcc were used out of convenience, since this is how it worked when the programs were first run on linux.

It would be good to replace gtk dependencies with those, if it needed it. I wonder how tr could run through Makefile's and switch these dependencies out.
Maybe. I've seen alot of applications where you can turn off things like gtk, so I wouldn't imagine, that with the applications I run, I would need to edit the Makefiles very much.

But it is good news! I didn't know that FreeBSD was going in that direction in ports also.
 
John Call
I've found out what you're looking for.
---
Use x11/xorg-minimal as Chris H suggested. Then remove
Code:
gmake
from the lines
Code:
USES
recursively from it's dependencies' Makefile's. Then comment out the lines
Code:
#USE_GNOME
. These ports are graphics/libdrm, x11/xkeyboard-config, and x11-servers/xorg-server. FreeBSD has it's native clang. You'll be surprised at how well this works.

You could also do this for the metaport x11/xorg, starting after x11/xorg-apps, but that would be "Xorg and dependency madness."
 
John Call : I agree with protocelt . I've plugged this quite a few times, as it's done me very well: have a look at ports-mgmt/poudriere. The ports system and package manager are now intertwined---ports are built into packages and registered with the pkg database on installation. Poudriere builds packages from the ports tree, and can keep track of build dependencies and such. Have a look at the BSD Now tutorial to get it up and running. The gist of it is this:
  1. Build and install ports-mgmt/poudriere or ports-mgmt/poudriere-devel.
  2. Write a list of ports you want to build in their <category/port_name> format to a file. You only need to include top-level ports (the applications you actually want to install).
  3. Create a build jail and ports tree as per the instructions in the poudriere(8) man page or on the BSD Now page I linked to.
  4. Issue the command poudriere options -j [file]<jail_name>[/file] -f [file]<ports_list_file>[/file]. That will let you set the knobs detailed in each port's Makefile. Those options are permanently stored for future builds You can also copy /etc/make.conf to /usr/local/etc/poudriere.d/make.conf and use it to set global knobs, such as removing NLS content. NOTE: This is time-consuming.
  5. Issue the command poudriere bulk -j [file]<jail_name>[/file] -f [file]<ports_list_file>[/file]. That will build all the ports on the list, including build and runtime dependencies.
Ports are built into packages and the finished packages are stored in the pkg(8) cache, so build dependencies are reused in future builds until a new version of a dependency is released. From my observation it seems that since all ports are built inside a jail Poudriere will (at least temporarily) install build dependencies within the jail to build ports, so you don't need them installed on the host system at all. All ports are also built in parallel, with the number of ports built equal to the number of physical CPU cores the system has, so the process is substantially more efficient that building one at a time or using ports-mgmt/portmaster.
 
Indeed not! and I wouldn't recommend it, aside from experimentation.
But the FreeBSD ports system /usr/ports/Mk provides a myriad of wonderful "KNOBS" to accomplish most anything one could hope for, and all via make.conf(5)! :)

--Chris
So can I override set options for specific individual ports using make.conf and /usr/ports/Mk/? Like if a specific Makefile calls for GCC, instead of the default, I can replace it with Clang? Or I can replace gmake with make, per port? I'll take a while to look at this, and try to understand it.
 
Anything not specifically about Xorg dependencies (like everything from post #13 on) should be in a separate thread.
 
Back
Top