Bug 192416

Removing the xfs dependency is purely a matter of configuring the X server to
not use it.  In the "Files" section do:

        #FontPath     "unix/:7100"
        FontPath     "/usr/share/X11/fonts/misc"

As for dropping all legacy fonts, the x server needs to find one font called
'fixed' or it wont start.  Personally, I don't think that should be fatal, the x
server should start even if it doesn't have any core fonts...  But anyway, all
modern applications use the fontconfig/freetype/Xrender code path for fonts, so
just shipping some cheesy small bitmap font as 'fixed' should satisfy the x
servers needs for core fonts.

As for the dependency chain, it might make sense to move the xfs dependency to
he tool that writes the xorg.conf with the xfs path in it.  As for the fonts
dependencies I guess my question is: how are we going to pull those in for
fedora if we remove the dep from the x server?

Oh, and longer term, we'd like to make the xserver just use fontconfig for
locating font, which will be one things less to configure in the server plus it
will be able to pick up fonts as they're added without restarting.

This is an interesting problem to solve.  ;o)  I think we need to solve this
in a way that works well for OLPC, and also works as best as possible for
Fedora and RHEL at the same time.  That way we have one codebase to work
with instead of multiple ways of doing this, each of which work best for
a subset of all users.  In other words, I think a single solution for
everyone is the best all around thing for us to do.

I've thought about it a bit, and discussed it in IRC with some people as well,
and I believe we should include the Fedora community in the process of
determining the best solution to the OLPC problem, which also works well
for our current userbase of Fedora (and RHEL).

Right now, all of our font rpms invoke chkfontpath upon font installation,
so all font packages have a dep on chkfontpath.  chkfontpath's sole
purpose currently is more or less to configure xfs to see any new font
directories that have been added.  So, chkfontpath depends on xfs in
order for the config file it modifies to be present.  The X server depends
on 2 fonts being present, "fixed", and "cursor".  So the dependency
chain goes like this:

Xserver -> fixed&cursor font (xorg-x11-base-fonts) -> chkfontpath -> xfs

In theory, we could have our config tools and OS upgrade scripts modify
the default xorg.conf (or user's current config) to directly contain
hard coded paths to the fixed/cursor fonts.  This would mean the X server
always has these fonts available at runtime and should work properly.

However, the font package's dependency on chkfontpath is a secondary
indirect dependency on xfs.  We would have to solve this dependency problem
as well.

Some brainstorming:

- Conditionalize chkfontpath invocation in the font rpm scripts to only
happen if xfs is actually installed, otherwise do not run chkfontpath.

- Simply remove chkfontpath invocation, and no longer support using xfs
by default install, nor with provided config tools.

- Leave chkfontpath invocation present, but modify chkfontpath to add
the paths directly to the X server config instead of the xfs config.

There are other possibilities I have in mind too, but in the interest
of keeping this initial review to a minimum, I'll leave them for another
time.

There are many different ways that the specific problem this was filed
for could be solved.  Some of those create new problems for current users,
and I would like to see a solution devised that solves the proposed OLPC
problem, while keeping the rest of the system running as smoothly as
possible for existing Fedora and RHEL users/customers as well.

I think it would be a good idea to have dialog with the Fedora community
on fedora-devel-list about this problem, in order to bring in a wider
range of input, as that may help us to come up with a better overall
solution which meets the needs of as many users as possible, while allowing
us to deprecate core font usage, yet still provide useable compatibility
with legacy apps.

Feedback appreciated.

I've just fired off an email to fedora-devel-list to encourage
the community to provide some feedback and ideas on how to tackle this
problem as a whole.  I'm hoping that we'll discover how people currently
use core fonts outside of the current default setup, and wether there
are any other unexpected reliances out there on core fonts that we should
be aware of.

With everyone's feedback we should be able to come up with a more well
balanced solution that meets the needs of the majority of the userbase
out there, while solving the OLPC xfs dependency issue at the same time.

Thanks in advance to anyone who responds.

As to chkfontpath dependency you may like to know all major Fedora Extra
packages do not depend on it even on a conditionalised way.

I just checked, and the Xorg server package does not have a dependency
on xfs, although I assumed that it did have.

pts/94
mharris@porkchop:/mnt/redhat/beehive/comps/dist/fc6/xorg-x11-server/1.1.0-1/i386$
rpm -qp --requires xorg-x11-server-Xorg-1.1.0-1.i386.rpm
/bin/sh
/bin/sh
/usr/bin/perl
libXau.so.6
libXdmcp.so.6
libXfont >= 0.99.2-3
libXfont.so.1
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libdl.so.2
libdl.so.2(GLIBC_2.0)
libdl.so.2(GLIBC_2.1)
libfontenc.so.1
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libgcc_s.so.1(GLIBC_2.0)
libm.so.6
libm.so.6(GLIBC_2.0)
libscanpci.so
libxf1bpp.so
libz.so.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
xkbcomp
xkbdata
xorg-x11-drv-keyboard
xorg-x11-drv-mouse
xorg-x11-drv-vesa
xorg-x11-fonts-base
xorg-x11-server-utils >= 0.99.2-5
xorg-x11-utils


This bug is filed against the xfs package, but I can't think of anything
that we'd do to the xfs package that would solve this.  It is only
chkfontpath package, and individual font packages that cause xfs to
be dragged in.

The X server package depends on xorg-x11-fonts-base, which of course
drags in chkfontpath, which will further drag in xfs, so that must be
the chain link to break.

How about one of these solutions:

[Solution 1]

- Create a new font package just for OLPC named "olpc-fonts-base", which
  contains only the misc fonts for the X server, and that package has
  "Provides: fonts-base".    This package will conflict with the
  xorg-x11-fonts-base, so that they're not ever both installed at the
  same time.

- I update the xorg-x11-fonts-base package to have "Provides: fonts-base"
  also.

- The X server packaging is changed to require the virtual "fonts-base"
  instead of the specific package it does now.

- OLPC installation, configures the X server to use hard coded font path
  which includes the fonts installed from olpc-fonts-base.  The font path
  should be:  $directory/misc:unscaled    The ":unscaled" is critical.



[Scenario 2]
- We change the default xfs configuration to no longer include the
  "misc:unscaled" font path.

- We change the X config tool to include a static font path pointing
  to misc:unscaled for all distro variants/etc.  For Fedora Core and
  RHEL installs, the second font path element is the xfs server, but
  for OLPC, no xfs server is configured.

- The xorg-x11-fonts-base subpackage is modified to NOT invoke chkfontpath,
  and the dependency on chkfontpath is then removed, losing the indirect
  dependency on xfs.


Notes:  Both of these scenarios will fail if OLPC requires any other font
packages that currently configure themselves to work in the core fonts
system by invoking chkfontpath.  In other words, in both of the above
scenarios, OLPC must _not_ require any xorg-x11-fonts-* packages or the
above scenarios will still fail.  Also, any other font packages included
in the OS, which are not part of the Xorg release, which OLPC requires,
must either not invoke chkconfig (and thus not be xfs visible), or we
have additional problems to solve.  I believe there are some other font
packages that we install which work with both font systems, which are
desireable working properly in both systems, so this may require more
work.

Thoughts?

ping

Wasn't Ajax working on integrating fontconfig into the server? If yes, would
that solve our problems and is it ready for the FC6 timeframe? Thanks.

he was, and then krh was, and then we sort of dropped it.  It's probably easier
to convince the X server to go scan for fonts directly and learn how to re-load
directories, since the pseudo-dynamism is all we're really using xfs for.

So, that'd get rid of xfs, and then your font package selection is orthogonal. 
I'll see what I can hack up.

We would really like to get this pulled out of OLPC.  It would save us many
megabytes.

The X server now builds with built-in 'fixed' and 'cursor' fonts, which means
that it can startup without any core fonts being present.  With this, we should
be able to drop the dependency on xorg-x11-fonts-base from the x server, so it
can be installed without that package and its dependency chain (which includes
xfs) being installed.  Most of the x server core fonts are pulled in by comps
anyway, so breaking this link shouldn't change anything, but it's not something
we want to change for FC6.

This should be fixed in current server olpc builds, yes?

Yeah, I think we're good now.