Re: Next steps for a reproducible Fontconfig?

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


Akira TAGOH <akira@xxxxxxxxx> writes:

> Hm, to deal with more complicated cases, I guess we may need to have
> one global salt to affect everything and a path-specific salt for
> remapped path.

Or, more likely, no salt at all for the outermost layer as it doesn't
really add anything here.

> for flatpak case, they want to have a global salt to
> change a salt in sandbox (for /usr/share/fonts in sandbox etc) and set
> salt from host in 'remap-dir' to build cache filenames on host (for
> /run/host/fonts and so on).

We may want a command line tool that extracts data from the config
for use by flatpak in building the dynamic configuration, including
things like salt values per directory. Yeah, that might be made to
work with flatpak essentially manually overriding the salt configuration
so that it uses the flatpak-relative names.

> This would avoid collision between one and origins. and assuming that
> flatpaks can load config from host too, we could have:
> 10-salt.conf (from host):
> <salt id="default"/>

I'd leave this out and not have salt in the host.

> 50-flatpak.conf (sandbox specific):
> <remap-dir as-path="/usr/share/fonts">/run/host/fonts</remap-dir>
> <salt id="randomdata"/>
> <dir>/usr/share/fonts</dir>

The salt here would need to have CDATA for the target directories, and I
think flatpack wants to split the dynamic from static config bits.

Dynamic (built at runtime):

 <remap-dir as-path="/usr/share/fonts" salt="">/run/host/fonts</remap-dir>
Static (built in the flatpak):

 <dir salt="salt">/usr/share/fonts</dir>

> First salt element affects to 'remap-dir' and second one overrides it
> for paths and change a salt in sandbox.

I think we can put that into the remap-dir element as both of those 
are built at runtime?

> To make things easier, we may also want to export all of dir elements
> from fonts.conf to the separate file. flatpak can replace it with
> 50-flatpak.conf in this case. or the file operation isn't desirable,
> let's implement dir-reset element or something like that.

I think a dir-reset makes a lot of sense so that the flatpak can control
the set of font paths used. Building a command-line tool that flatpak
can use to discover the relevant fontconfig information seems like a
useful improvement; as I recall, flatpak is currently assuming
/usr/share/fonts and ~/.fonts are used on the host.


Attachment: signature.asc
Description: PGP signature

Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux