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
