Fontconfig - Nov 2005 - Tools to ensure at least minimal functionality

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

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.
-- 
 .''''`.           Josselin Mouette        /\./\
: :'' :           josselin.mouette@ens-lyon.org
`. `''                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20050124/4554b978/attachment.pgp

Around 18 o''clock on Jan 24, Enrique Perez-Terron wrote:
> 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.
fc-cache isn''t necessary (or at least isn''t supposed to be
necessary); it''s
simply a way to share cached font information for multiple users.

Any other behaviour is a bug somewhere.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20050124/d68a2cac/attachment.pgp

Hello,

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 could be implemented using two tools, one that tests the basic
functionality of the font rendering libraries, and one that simply
produces a list of files that potentially influences the process.

The reason I post here is that some aspects of such tools are perhaps
much easier to maintain for those who know the font handling software
intimately. I guess that for fontconfig''s maintainer it would be a
complete no-brainer to maintain a script that lists in order all files
looked at during the font matching process. Then it would be for the
distribution maintainer to rename all such files out of the way unless
they were strictly as distributed, until the basic functionality is
confirmed.

For the maintainers of the various distributions of the various free
os''es to investigate in turn what it takes to make at least some basic
aspects of the install/upgrade procedures really foolproof - and keep
that up to date as the zillion libraries change - that is error prone,
to say the least; and this kind of issues will in the long run
inevitably place an upper limit to the percieved quality of even the
major distributions - unless we find ways of addressing them.

I am not quite so sure about how to test the basic functionality.  The
end result depends on any number of layers of libraries, freetype,
pango, you name it. Kde would have its stack, fltk another...

Do you have any thoughts about this?

-- 
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/20050123/8ac67551/attachment.pgp