[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 Thu, Feb 02, 2006 at 09:03:00PM +0100, Dejan Lesjak wrote:
> 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).

OK, whatever is easiest :)

Kris

Attachment: pgpR6l6NOgcaJ.pgp
Description: PGP signature