[Fontconfig] Tools to ensure at least minimal functionality

[Enrique Perez-Terron]

On Mon, 2005-01-24 at 13:56 +0100, Josselin Mouette wrote:
> Le dimanche 23 janvier 2005 à 19:29 +0100, Enrique Perez-Terron a
> écrit :
> > I just upgraded my FC2 box to FC3 and found that the display manager gdm
> > was unable to show the login prompts. Instead it kept restarting every
> > few seconds, switching to virtual console 7 each time - making it quite
> > hard and unpleasant to recover.
> > 
> > It turned out to be due to a config.cache-1 file listing non-existent
> > Vera.ttf and friends. This was the first font on the list of preferred
> > sans-serif fonts.
> > 
> > While this is really something that the gdm maintainers should look at,
> > it made me think a step further:  The distributions'
> > installation/upgrade software need to check that at least the user root
> > has a minimally working font configuration, no matter what the users
> > have left behind of configuration files that worked or did not work with
> > the previous os.  
> 
> This is all what dependencies are about. I fail to see why things should
> be different for the font subsystem.
> 
> As for the problem you are talking about, this is probably a matter for
> the upgrade scripts. fc-cache should be run automatically after each
> installation or uninstallation of font packages.

That is a good recipe to ruin the perception the free software world is
trying to build, that it is so much more reliable than certain brands of
commercial software.

In this case the upgrade script should run fc-cache in all directories
containing fonts, whether or not any fonts had been installed or
uninstalled there. That means the upgrade script must parse the user's
configuration files to locate the directories.

Errors are a fact of life, and sooner or later (in this case sooner; it
already happened) some fonts will get installed or uninstalled without
fc-cache being run. Or, it was run but there was a bug in fc-cache, I
don't know.

I do not know just how much different this is for the font system, but
in this case the system became absolutely unusable - not just the font
system, the whole computer became perfectly useless to all but the most
sophisticated users.  That is a tad more serious than most other
problems.

We can probably never build into our systems resilience and recovery
from all sorts of misconfigurations and mishaps, but we could consider a
few highly critical cases.  While of course the major issues must be
dealt with in install/upgrade scripts, it is still conceivable that
subsystem developers could lend a hand and offer some cheap but useful
tools to help out with things related to that subsystem.

I do not know how the above problem actually arose. Most likely the vast
majority of users did not experience this problem at all. (Otherwise the
distribution folks would have attacked it and solved it ad hoc.)  My
point is to look a few steps further.  How can a distributor ensure that
the target computers will reboot and be usable after an upgrade?  Notice
the difference, a fresh install is way simpler.  The upgrade problem is
very open-ended. Each possible problem has a low likelihood, yet a
perceptible fraction of the upgraders experience trouble in one way or
another. 

I believe that the best way to make "the linux experience" (or free-bsd,
open-bsd, etc) a pleasant one is to take a systematic and thorough
approach to quality assurance.  One step here is to be able to remove
obstacles so at least the root user can log in after an upgrade. But
even the list of possible obstacles is quite open-ended, as seen from
the perspective of the distribution maintainer.  It is, I believe, much
less so from the perspective of the individual subsystems.  

Of course, the distribution maintainers are quite capable people, and
they are certainly capable of solving the particular problem at hand if
you point them at it.  But even so it may imply reading code for, say,
ten hours, before writing a fix in ten minutes. Multiply with ten
distributions (there are more, but many borrow features from each other
- the spirit of free software) and multiply by the number of
distribution releases.  They will have to re-read the code pretty much
from scratch for each release, as they cannot possibly remember much
from the previous time around after having delved into the internals of
a zillion other subsystems as well.  

The subsystem maintainers perhaps design and implement a tool in an hour
or two, and do only minimal maintenance for subsequent releases, as they
might know the configuration sources have not changed at all.

Excuse me for bombing you with such a long and verbose post.  Could we
go on to consider what exactly it takes to ensure that the font system
is capable of rendering the basic fonts: serif, sans, and fixed?  

Or, to put it differently, how many ways can you come up with to
sabotage the next upgrade? (A "negative" approach is sometimes more fun.
Imagine you want to play a practical joke on a fellow that you know is
going to upgrade the OS of a computer which you too have access to.)

-- 
Regards,
Enrique Pérez-Terrón
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050124/e4751de3/attachment.pgp