[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ports-i386@xxxxxxxxxxx: gtk-2.8.11 failed on i386 6]



On Thursday 02 February 2006 20:35, Kris Kennaway wrote:
> On Thu, Feb 02, 2006 at 02:25:21PM -0500, Joe Marcus Clarke wrote:
> > Dejan Lesjak wrote:
> > > On Thursday 02 February 2006 18:35, Joe Marcus Clarke wrote:
> > >> On Thu, 2006-02-02 at 17:43 +0100, Dejan Lesjak wrote:
> > >>> [fontconfig maintainers cced]
> > >>>
> > >>> On Thursday 02 February 2006 17:18, Kris Kennaway wrote:
> > >>>> This failure is caused by the following files left in the directory
> > >>>> after xorg-font-encodings has been removed:
> > >>>>
> > >>>> -rw-r--r--  1 root  wheel  17 Feb  1 19:53
> > >>>> /usr/X11R6/lib/X11/fonts/encodings/fonts.cache-1 -rw-r--r--  1 root
> > >>>> wheel 0 Feb  1 19:53
> > >>>> /usr/X11R6/lib/X11/fonts/encodings/large/fonts.cache-1
> > >>>>
> > >>>> These are then removed by fontconfig, but nothing cleans up the
> > >>>> directories.  What should be doing that?
> > >>>
> > >>> Interesting question.  fontencodings don't create fonts.cache-1, but
> > >>> it will probably be easier and less messy if they remove them so they
> > >>> can also remove directories. Can it be assumed that fontconfig is
> > >>> present at the time fontencodings are uninstalled?
> > >>
> > >> Not necessarily.  fontconfig is only a build dependency of
> > >> xorg-font-encodings.  Therefore, you could remove fontconfig, and keep
> > >> encodings around.
> > >
> > > Oh. The thing is that it's easy to check if
> > > encodings/large/fonts.cache-1 is empty and remove it in that case. On
> > > the other hand encodings/fonts.cache-1 contains the line pointing to
> > > "large" subdir so I was thinking of first removing
> > > encodings/large/fonts.cache-1 if it is empty, then encodings/large
> > > directory, then running fc-cache on encodings and remove
> > > encodings/fonts.cache-1 if it's empty. If fc-config is not present some
> > > parsing will be necessary...
> > > Is there a way fc-cache could ignore encodings subdirectory?
> > >
> > >> The strange thing is that fontconfig removes all
> > >> fonts.cache-1 files under /usr/X11R6/lib/X11/fonts upon
> > >> deinstallation.
> > >
> > > Perhaps generating and removing cache files should be made
> > > responsibility of fonts ports? IIRC quite some of them handle it
> > > already. That could also avoid running fc-cache with default settings
> > > thus avoiding fonts.cache-1 files under encodings.
> >
> > This is doable.  I could remove the cache generation and cleaning code
> > from fontconfig once all font ports have been updated to run fc-cache
> > themselves.  This would require all font ports to depend on fontconfig,
> > though.
>
> Wouldn't it be less work to just make fontconfig @dirrmtry the
> directories it removes cache files from? 

That would be somewhat like
@unexec find %%X11BASE%%/lib/X11/fonts/ -type d -empty -delete

> That way you also don't have 
> to worry about fontcache never operating on non-port font directories
> the user may have created.

It's not that trivial: unless explicitly specifying directory to it, fc-cache 
will run on directories specified in ${X11BASE}/etc/fonts/fonts.conf (and any 
included file). Among others this means all subdirectories of 
${X11BASE}/lib/X11/fonts. If a user would make a directory 
${X11BASE}/lib/X11/fonts/mumble, fc-cache will happily populate it with empty 
fonts.cache-1 file. Passing responsibility to run fc-cache to fonts ports 
would avoid that (at least as far as ports go; user can still run fc-cache 
without directory argument of course).


Dejan