Fontconfig - Oct 2011 - pre-creating font caches in a different tree

i''d like to run fc-cache against a different tree than "/". 
a lot of utils
have a "--root" flag for this sort of thing.  this is useful for
distros which
are preparing packages for installation.  it avoids having to run fc-cache on 
every system that deploys the fonts.

so if i ran `fc-cache -s --root /a/b/c`, it would look at /a/b/c/etc/fonts/ 
instead of /etc/fonts/.  then every dir that those config files said to use 
would transparently be prefixed with /a/b/c.  so if my config said 
<dir>/usr/share/fonts</dir> and
<cachedir>/var/cache/fontconfig</cachedir>, it
would instead scan /a/b/c/usr/share/fonts and store the cache in 
/a/b/c/var/cache/fontconfig.

how hard do people envision this being ?
-mike

On 10/04/11 14:45, Mike Frysinger wrote:
> i''d like to run fc-cache against a different tree than
"/".  a lot of utils
> have a "--root" flag for this sort of thing.  this is useful for
distros which
> are preparing packages for installation.  it avoids having to run fc-cache
on
> every system that deploys the fonts.
> 
> so if i ran `fc-cache -s --root /a/b/c`, it would look at /a/b/c/etc/fonts/
> instead of /etc/fonts/.  then every dir that those config files said to use
> would transparently be prefixed with /a/b/c.  so if my config said 
> <dir>/usr/share/fonts</dir> and
<cachedir>/var/cache/fontconfig</cachedir>, it
> would instead scan /a/b/c/usr/share/fonts and store the cache in 
> /a/b/c/var/cache/fontconfig.
> 
> how hard do people envision this being ?
Why can''t you just do "chroot /a/b/c fc-cache -s"?

behdad
> -mike

On Tuesday 04 October 2011 22:36:08 Behdad Esfahbod
wrote:
> On 10/04/11 14:45, Mike Frysinger wrote:
> > i''d like to run fc-cache against a different tree than
"/".  a lot of
> > utils have a "--root" flag for this sort of thing.  this is
useful for
> > distros which are preparing packages for installation.  it avoids
having
> > to run fc-cache on every system that deploys the fonts.
> > 
> > so if i ran `fc-cache -s --root /a/b/c`, it would look at
> > /a/b/c/etc/fonts/ instead of /etc/fonts/.  then every dir that those
> > config files said to use would transparently be prefixed with /a/b/c. 
> > so if my config said <dir>/usr/share/fonts</dir> and
> > <cachedir>/var/cache/fontconfig</cachedir>, it would
instead scan
> > /a/b/c/usr/share/fonts and store the cache in
> > /a/b/c/var/cache/fontconfig.
> > 
> > how hard do people envision this being ?
> 
> Why can''t you just do "chroot /a/b/c fc-cache -s"?
not everyone has that access.  building as root is a bad idea.

long term, i want to do this for cross-compiling, and obviously chroot
won''t
work either (ignoring workarounds involving qemu).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20111004/cdf31a2b/attachment.pgp>

On 10/04/11 23:13, Mike Frysinger wrote:
> On Tuesday 04 October 2011 22:36:08 Behdad Esfahbod wrote:
>> On 10/04/11 14:45, Mike Frysinger wrote:
>>> i''d like to run fc-cache against a different tree than
"/".  a lot of
>>> utils have a "--root" flag for this sort of thing.  this
is useful for
>>> distros which are preparing packages for installation.  it avoids
having
>>> to run fc-cache on every system that deploys the fonts.
>>>
>>> so if i ran `fc-cache -s --root /a/b/c`, it would look at
>>> /a/b/c/etc/fonts/ instead of /etc/fonts/.  then every dir that
those
>>> config files said to use would transparently be prefixed with
/a/b/c.
>>> so if my config said <dir>/usr/share/fonts</dir> and
>>> <cachedir>/var/cache/fontconfig</cachedir>, it would
instead scan
>>> /a/b/c/usr/share/fonts and store the cache in
>>> /a/b/c/var/cache/fontconfig.
>>>
>>> how hard do people envision this being ?
>>
>> Why can''t you just do "chroot /a/b/c fc-cache -s"?
> 
> not everyone has that access.  building as root is a bad idea.
Fair enough.

It''s not hard adding this to the library.  You would need to add
something
like FcConfigSetRoot() / FcConfigGetRoot(), and modify the five or so
locations that files are accessed.

behdad
> long term, i want to do this for cross-compiling, and obviously chroot
won''t
> work either (ignoring workarounds involving qemu).
> -mike

Twas brillig at 23:13:34 04.10.2011 UTC-04 when vapier at gentoo.org did gyre
and gimble:

 MF> long term, i want to do this for cross-compiling, and obviously
 MF> chroot won''t work either (ignoring workarounds involving qemu).

The bigger problem with cross-compiling will be mismatch between host
and target endianness and lengths of types.

Have you looked into it? I have tried to approach this problem both from
direction of making fc-cache aware of different architectures, and from
direction of creating fc-cache-recode to convert caches to match target
architecture, but both seems to be quite hard to achieve.

-- 
  http://fossarchy.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20111005/a3572efd/attachment.pgp>

On Wednesday 05 October 2011 02:28:02 Mikhail Gusarov
wrote:
> Twas brillig at 23:13:34 04.10.2011 UTC-04 when vapier at gentoo.org did
gyre
> and gimble:
> 
>  MF> long term, i want to do this for cross-compiling, and obviously
>  MF> chroot won''t work either (ignoring workarounds involving
qemu).
> 
> The bigger problem with cross-compiling will be mismatch between host
> and target endianness and lengths of types.
i''m aware of this.  that''s why i''m trying to keep it
as a sep issue :).
> Have you looked into it? I have tried to approach this problem both from
> direction of making fc-cache aware of different architectures, and from
> direction of creating fc-cache-recode to convert caches to match target
> architecture, but both seems to be quite hard to achieve.
i''ve thought of both ways, but haven''t looked too closely to
see which would
be easier.  i''d lean towards the latter after seeing the defines like 
ARCHITECTURE being setup.  but i''ll start a new thread for this.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20111005/1010a8b2/attachment.pgp>

On Wednesday 05 October 2011 00:01:04 Behdad Esfahbod
wrote:
> On 10/04/11 23:13, Mike Frysinger wrote:
> > On Tuesday 04 October 2011 22:36:08 Behdad Esfahbod wrote:
> >> On 10/04/11 14:45, Mike Frysinger wrote:
> >>> i''d like to run fc-cache against a different tree
than "/".  a lot of
> >>> utils have a "--root" flag for this sort of thing. 
this is useful for
> >>> distros which are preparing packages for installation.  it
avoids
> >>> having to run fc-cache on every system that deploys the fonts.
> >>> 
> >>> so if i ran `fc-cache -s --root /a/b/c`, it would look at
> >>> /a/b/c/etc/fonts/ instead of /etc/fonts/.  then every dir that
those
> >>> config files said to use would transparently be prefixed with
/a/b/c.
> >>> so if my config said <dir>/usr/share/fonts</dir>
and
> >>> <cachedir>/var/cache/fontconfig</cachedir>, it
would instead scan
> >>> /a/b/c/usr/share/fonts and store the cache in
> >>> /a/b/c/var/cache/fontconfig.
> >>> 
> >>> how hard do people envision this being ?
> >> 
> >> Why can''t you just do "chroot /a/b/c fc-cache
-s"?
> > 
> > not everyone has that access.  building as root is a bad idea.
> 
> Fair enough.
> 
> It''s not hard adding this to the library.  You would need to add
something
> like FcConfigSetRoot() / FcConfigGetRoot(), and modify the five or so
> locations that files are accessed.
ok ... i just wanted to make sure people were generally on board with the idea 
before spending time coding up something :).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20111005/5913e3eb/attachment.pgp>