Kernel docs and X11. [solved]

[1clue]

Sorry if this is in the wrong spot, but I think it makes more sense to put it here than in the feedback forum from the "doc -X" stuff.

I'm installing a headless system on an old crappy box I'm trying to breathe a bit more life into. I have followed the chain of forum and documentation links all the way out to:

[1clue]

More information on this.

Every time I try to mention this topic, somebody thinks it's old news and not worthy of their time, but IMHO if it's important to anyone who wants to get the kernel documentation without having to load X, it's worth somebody's time.

If you disable sdl from www-client/links, Portage no longer tries to load X when you try to load hardened-sources +doc.

SDL is Simple Direct Layer, for media. If you go to their web site, they mention that it is possible to get a build of SDL without X11, but it's an error according to the Linux FAQ. SDL wants a window manager or it does not work properly.

However, it seems to me that if somebody builds links with -X, it means they do not want any window manager: They want a text-based web browser for a system which is either a server or is a bare-bones workstation. That implies to me that MOST people who build links without X will not want the sdl code either, since their web site implies that the library is GUI-oriented. It seems that it would be reasonable for the -X flag on links to disable sdl too by default, and then anyone who wants sdl can add it to their USE variable in one of the standard places, at which point they can figure out how to build it without X.

I think this indicates that EITHER media-libs/libsdl is broken by requiring X (not likely, since it seems to be focused around a GUI) OR www-client/links is broken by loading sdl when -X is specified. My opinion is that it's the latter.

There are two ways I can think of to fix this, and to simplify the Gentoo installation documentation at the same time:
1 Alter the ebuild for links so -X implies -sdl
2 Alter the default USE for links to include -sdl.

Input to this would be appreciated.

Thanks.

[1clue]

OK, I finally saw the light.

Even after having read the portage documentation 3 times, I still missed it even though it's fairly obvious once you see it. I'm adding this post in hopes that somebody else who is as dense as me can figure it out before trying to butt heads with somebody on bugzilla.

/etc/make.conf does not define all of USE.

/usr/portage/profiles/default-linux/x86/2005.1/make.defaults defines some base USE flags. Other places define more of them, all of which is actually in the Portage documentation, in plain sight.

Reiterating for those who might still be a bit faster than I was: make.conf's USE flags ADD TO and SUBTRACT FROM a USE variable which IS NOT EMPTY!

USE flags are ADDITIVE. The fact that you can negate a flag with -flag is misleading if you don't remember that some prior file got your USE variable before make.conf sees it. IF you keep the heirarchy in mind, it makes all kinds of sense.

-X compiles packages which OPTIONALLY require X without it. If you still have kde, gnome or any other X-related flag active from /usr/portage/profiles/default-linux/whatever/make.defaults, YOU WILL GET X! X is REQUIRED for these packages! Worse yet, you will have ASKED for it because the make.defaults assumes a GUI system.

Here's the good news:
1 Rather than disabling every USE flag that is known to humanity, you need only get the make.defaults ones and prune those down.
2 If you're brave enough or if you don't mind reinstalling if you mess up, you can define USE="-* doc perl whatever ..." and you will ONLY get what's in your make.conf and, if you have it, your package.use files. In that case, you have to specify EVERY option you want, which was somehow what I thought I was doing.
3 Adding things with USE takes extra CPU time because it compiles more packages. Subtracting things from USE speeds it up, no matter how long that USE variable gets.

This is extremely frustrating, because I read the documentation several times and still had to butt heads with somebody on bugzilla in order to see the light. Reading the documentation again, I don't see where it really needs to be improved.

I stand in for support for my own company sometimes, and I HATE when people do that to me. I'm a developer with decades of experience, and I've been a !@% moron.

1clue--