Maybe this has been discussed before, but I didn't see mention of it in bugzilla so I'll just go ahead and put this in. One of the things that I miss about running "that other distribution" is the ability to install only parts of the monster that is xfree. For example, I only usually install the 100dpi fonts. I never install the ISO8859 fonts. And so on. xfree-4.2.1 installs 7495 files with my current USE settings. If there were some tweakable settings there, I could cut this down to 3591 files just by not installing the ISO8859 fonts. That's a major savings and there's others as well. I will never use the cyrillic fonts for example (only 71 files, but still...). I have -opengl set in USE and yet all the opengl stuff is built and all the man pages are installed for opengl. That's another 550 files. Request for enhancement... Reproducible: Always Steps to Reproduce: 1. emerge xfree Actual Results: A ton of things that I will never need, yet would be relatively easy to remove from the xfree build get installed. Expected Results: xfree ebuild should at least honor -opengl but it would be nice if a couple more use variables were added to support more configurability of the build. USE="-font_75dpi -font_cyrillic -font_ISO8859" That's ugly, but the idea is there. Portage 2.0.47-r8 (default-1.0, gcc-2.95.3, glibc-2.2.5-r2,2.2.5-r7) ================================================================= System uname: 2.4.19-gentoo-r7 i586 Pentium MMX GENTOO_MIRRORS="http://csociety-ftp.ecn.purdue.edu/pub/gentoo http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/bash_completion /etc/X11/serverconfig /etc/X11/starthere /etc/ssmtp /etc/sound/events /etc/X11/rstart /etc/X11/xdm /etc/pango /etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow apm crypt cups encode libg++ mikmod mmx mpeg ncurses pdflib spell truetype xml2 xmms xv berkdb esd gdbm gif gnome gnome-libs gtk guile java libwww oggvorbis pam perl png python readline slang snmp ssl tcpd tetex tiff X -jpeg -avi -dvd -opengl -doc -quicktime -sdl -svga -motif -nls -imlib -kde -qt -arts gpm mozilla gtk2" COMPILER="" CHOST="i586-pc-linux-gnu" CFLAGS="-march=i586 -O3 -pipe" CXXFLAGS="-march=i586 -O3 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox distcc ccache"
michael, work has begun on xfree-4.3.0-r3 with exactly this in mind. the preliminary ebuild is at: http://cvs.gentoo.org/~seemant/xfree-4.3.0-r3.ebuild But note that the final ebuild will act a lot differently, as this is just the starting point. I am tending towards pulling ALL the font stuffs out of xfree entirely, and putting them into their own ebuilds in media-fonts.
*** Bug 33421 has been marked as a duplicate of this bug. ***
*** Bug 30168 has been marked as a duplicate of this bug. ***
Some of this is in xorg-x11-6.8.0-r2. We've got bitmap-fonts (100 and 75 dpi), type1-fonts, truetype-fonts, dri and glx. glx will stop most of the opengl stuff -- I can make it stop any remainders once I find the defines for them, if you tell me there's stuff left over.
But as far as I can see it should be possible to split xorg at least partially w/o major hacking. Eg. fonts can be installed using a seperate ebuild. (Patch out program, libs... target in root Imakefile...etc) Only problem is the support for certain types of fonts. I haven't understood yet, whether this can be done seperately. I think handling fonts would be a first step, as there are loads of defines there, so that nearly everything there could be cut down. Doing this by flags seems like too much, but maybe do it similar as glibc does with userlocales? You use a seperate file for defining stuff in /etc?
OK, issue is: it's been tried, it's more complex than it would seem to build just fonts, because it also wants to build a bunch of utilities, install a bunch of imake configuration stuff, etc. As a result, splitting out the utils and imake stuff into a separate package was tried, but it's also fairly difficult to get it to use the installed things and to just build and install those things. Work's stalled in this area due to lack of time and motivation, because upstream's got tentative plans for an official modular release.
So my first experiment: In root Makefile target World comment the line if [ -z "$(FAST)" ]; then $(MAKE_CMD) $(MFLAGS) depend; fi (What would be the proper fix?) Then in root Imakefile change SUBDIRS to SUBDIRS = lib/font/stubs programs/bdftopcf programs/mkfontscale ${FONTSDIR} Then run make World. Now it seems the fonts get properly built. I haven't installed them and haven't tested all combinations, but is this they way to go to get a "xorg-fonts" ebuild?
@Donnie Hmm, I haven't got a mail about your response, so I read it after posting. When was it tried to split fonts? I don't know how long it takes to get x.org done modularization. At least from my little experiment it *seems* it is not too diffivult with current xorg release.
How about `make install` -- what do you get installed? Are you building anything more than what's needed? Will any of the built stuff be duplicated in the other side of the split? Can you do this in a way that would be acceptable to upstream rather than being a complete hack? The last question is the primary constriction on this. In general, the Right Way(tm) to do this will be configuration in host.def and hacking Imakefiles around to build what's needed. This will include things like BuildFonts YES and turning off whatever else builds by default.
make install went through w/o problems and it seems it did install the fonts. (excerp: installing in fonts/util... make[3]: Entering directory `/var/tmp/portage/xorg-x11-6.8.1.904/work/xc/fonts/util' + install -c -m 0444 map-ISO8859-1 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-2 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-3 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-4 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-5 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-7 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-8 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-9 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-10 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-11 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-13 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-14 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-15 /usr/share/fonts/util + install -c -m 0444 map-ISO8859-16 /usr/share/fonts/util + install -c -m 0444 map-JISX0201.1976-0 /usr/share/fonts/util + install -c -m 0444 map-KOI8-R /usr/share/fonts/util ) Duplication: Currently, yes. The tiny libs/utils I put to subdir will be build in unpatched xorg I guess (need to take a closer look though) Well, for a "real thing" I need to find out the dependecies for each font type and then implement more #ifdefs into the (I)makefiles. I don't think it is too hackish at the moment... Buit as I said, the only thing left is, xorg probably needs libs to "understand" the fonts at runtime. So either build them all while emerging xorg or better find out how to do this in the "fonts ebuild" and do so.
Ok, I have been playing around with xorg and got to a problem now, which I don't quite understand. Besides the fonts (which are not a big problem, as far as I can see) I am trying to build the libraries belonging to them. So I did this in root Imakefile: SUBDIRS = include config lib/font [...] whereas original was SUBDIRS = include config lib [...] But it dies in lib/font/bitmap with: In Datei, eingef
Ok, I have been playing around with xorg and got to a problem now, which I don't quite understand. Besides the fonts (which are not a big problem, as far as I can see) I am trying to build the libraries belonging to them. So I did this in root Imakefile: SUBDIRS = include config lib/font [...] whereas original was SUBDIRS = include config lib [...] But it dies in lib/font/bitmap with: In Datei, eingefügt von bdfread.c:61: ../../include/bitmap.h:43:24: xf86_ansic.h: Datei oder Verzeichnis nicht gefunden So xf86_ansic.h cannot be found, which resides deep in programs..bla...xfree85/os_something I wonder how even the unpatched build system would work? Even when I modified lib/font back to lib it wouldn't go further. The programs dir will only be built after the lib dir, so any insights? Or have I overseen something in the ebuild? I did a ebuild ... unpack and started working on the sources.
*** Bug 83626 has been marked as a duplicate of this bug. ***
This is as fixed as it's going to get with the monolithic Xorg. As the modular efforts proceed upstream, we'll be moving to them.
