Re: Is fc-cache broken on -current?

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

walt wrote:

> Jeremy C. Reed wrote:
>
> > On Thu, 28 Sep 2006, Bill Hacker wrote:
> >
> >
> > > walt wrote:
>
>
> > > > The problem was that those config files should have been
> > > > replaced during the update!
>
>
> > > Ordinarily NOT by the 'update'. But by the 'updater',
> > > .. with care to preserve whatever customization...
>
>
>
> > In the case of fontconfig, the fonts.conf file should not be manually 
> > edited by the admin as the customizations should be in local.conf.
>
>
> Right.  'fonts.conf' has a big banner at the top, cautioning the
> admin *not* to edit the file.  The concept of a 'config' file which
> must not be edited is a bit bizarre, IMO.  That sort of 'config' is
> done at compile-time (usually).
>
> This means that the fontconfig package *should* replace at least
> those 'do-not-edit' config files without asking.

Despite the fact that I am personally a 'worst-case offender' and regularly say 
'sod that, if it isn't to be altered it should be a binary' - and edit the core 
files rather than make chained exceptions

- I do agree 100% that this should be the 'expectation'.

*however* - if the fingerprint DOES NOT MATCH, I would still far rather have the 
installation/upgrade process throw a flag and leave it for manual action.

Regardless of cause. It is just less 'damaging'.

It may not be that the 'luser' has messed with it, but that it is not even from 
the same rev level or *architecture* (think FreeBSD 6.1 i386 vs 6.1 AMD-64 SMP - 
either of which will run on Intel Dual-core as well as AMD....

Only problem is an ancient one - those inlined warnings are almost always 
missed, even if you DO watch the screen - 'specially wityh fast systesm....

A broader 'fix' DFLY might be able to convey to the POSIX world is a way to 
separate-out such message types from the spew of '-WALL ....'

. .. ACK... 'dream on, Bill'...

Bill