Releases/FeatureNoMoreXFS

Do not use xfs by default

Summary

We want to disable running a font server by default.

Owner

• Name: KristianHoegsberg, AdamJackson

Current status

• Targeted release: Fedora 8
• Last updated: 2007-10-02
• Percentage of completion: 100%

xfs is fixed. All font packages are fixed. See documentation section.

Usage cases/rationale

xfs is an unnecessary complication of our setup, that was introduced because we had the chkfontpath tool that let us rewrite the xfs config file and restart it. This dates back to the XFree86 days when the upstream wasn't very cooperative and we didn't have a lot of development resources on X. Now that we can fix the problems instead of working around them, this is the right way to go.

xfs is one of the slower bits of system startup and eats up system resources. By not starting it, we'll boot faster. Running fewer system daemons is a good thing, and all in all this simplifies the whole X setup.

Scope

• Change both the font and X server to read font paths from a /etc/X11/fontpath.d directory, via code in libXfont - DONE
• Modify the font installation scripts and packages to add the proper links
• Remove xfs from the default install groups - DONE

Test Plan

Do a basic install. Make sure xfs is not running, and is not installed. Test that X properly handles the addition and removal of font packages at runtime.

Dependencies

According to repoquery, the following required chkfontpath. They have all been fixed now.

fonts-KOI8-R-75dpi-0:1.0-9.1.1.noarch
efont-unicode-bdf-0:0.4.2-6.1.fc6.noarch
fonts-KOI8-R-100dpi-0:1.0-9.1.1.noarch
fonts-ISO8859-2-0:1.0-17.1.noarch
fonts-japanese-0:0.20061016-6.fc7.noarch
fonts-korean-0:1.0.11-9.1.1.noarch
fonts-x11-apl-0:4.20.2-19.fc8.x86_64
wqy-bitmap-fonts-0:0.8.1-6.fc8.noarch
fonts-truetype-apl-0:4.20.2-19.fc8.x86_64
x3270-x11-0:3.3.4p7-5.fc6.x86_64
fonts-ISO8859-2-100dpi-0:1.0-17.1.noarch
fonts-chinese-0:3.03-4.fc7.noarch
fonts-ISO8859-2-75dpi-0:1.0-17.1.noarch
fonts-KOI8-R-0:1.0-9.1.1.noarch
terminus-font-x11-0:4.20-5.fc6.noarch
zvbi-fonts-0:0.2.25-1.fc8.x86_64
grace-0:5.1.21-1.fc7.x86_64
libdockapp-fonts-0:0.6.1-3.fc8.x86_64

A tracker bug for these changes is here

Documentation

Third party font packages, if any, will need to drop their configuration symlink in /etc/X11/fontpath.d rather than run chkfontpath. Note that you only need to do this if you want the fonts to be available over the old core font mechanism. If you're just doing client-side fonts (as both gtk and qt do nowadays) then you can demolish the chkfontpath call entirely.

What I've done for the packages I've updates (the xorg-x11 font packages) is to install the symlink in %install and just list it in the %files section. For 3rd party core font RPMs I recommend using the package name as the symlink name to avoid conflicts if you install the fonts in a non-standard directory. For example, from the ghostscript-fonts specfile:

%define fontdir %{_datadir}/fonts/default/ghostscript
%define catalogue /etc/X11/fontpath.d
...

%install
...
mkdir -p $RPM_BUILD_ROOT%{catalogue}
ln -sf %{fontdir} $RPM_BUILD_ROOT%{catalogue}/ghostscript

%files
...
%{catalogue}/ghostscript

/etc/X11/fontpath.d has been added to the filesystem package, so font packages should not own that directory.

Release Notes

http://hoegsberg.blogspot.com/2007/06/death-to-xfs.html. Use this blog post as a reference.

Comments

The rationale is a bit weak, imo. The main point is that all modern applications have switched to client-side fonts, so running a separate font server for core fonts is just eating unnecessary resources, when the X server itself can handle the occasional core font request just fine (MatthiasClasen). Updated rationale (KristianHoegsberg).

Will font packages need fixing? If so, instructions need to be written ASAP so that things can get fixed soon.

• The instructions can be found further up in the section called "Documentation". Also note that Kristian and I already provided patches for a number of font packages. (MatthiasClasen)

• If you add us to the acls of the packages in question, we'll even happily build the fixes ourselves (MatthiasClasen).

Will the stupid "kill X if core fonts are not found" check be killed? On a modern system people wouldn't care less if xfs is run or not. They do mind if the GUI part dies just because a subsystem no modern app uses is not initialised properly. -- NicolasMailhot

We have had the required couple of core fonts compiled in since F7, so you should never see that problem again, unless you explicitly set a bogus font path.

Unfortunately quite a few of the fixed fonts packages now own %{catalogue}. -- JensPetersen

• CJK ones should be fixed now though

---