Le lundi 12 novembre 2018 à 15:30 +0100, Alexander Larsson a écrit :
> On Mon, Nov 12, 2018 at 3:25 PM Nicolas Mailhot
> <nicolas.mailhot@xxxxxxxxx> wrote:
> > Le 2018-11-12 14:39, Alexander Larsson a écrit :
> > > This identifier
> > > used to be the pathname, but that doesn't work once you start
> > > using
> > > filesystem namespaces to rearrange where directories appear.
> >
> > Unless you provide a mapping file that gives the correspondence
> > between
> > the file paths ids stored in the reused fontconfig cache and the
> > file
> > paths exposed by the container layer. And this mapping file can work
> > with any method of font directory remapping, via
> > containers/nfs/whatever, without requiring writes (reproducible or
> > not)
> > to the font directories themselves. And unless you are moving things
> > all
> > over the place continuously, the mapping file can be a static config
> > that pretty much never changes.
>
> Its not that hard to define the mapping of the host /usr/share/fonts
> into the container. However, this is not enough, because you will then
> use "/usr/share/fonts" as the cache key for this directory, which
> conflicts with the /usr/share/fonts in the container.
So what? That just changes directory scanning to
if (not hit(key(entry), maincache)) and remapped(entry) and
hit(key(preremap(entry)), mappedcache) then
copy(data(key(preremap(entry)), mappedcache), maincache)
else
computedata(entry, maincache)
end
in quick and dirty handwaiving pseudocode
As a bonus you do not poison the main cache with host cache data relate
to things not mapped in the container.
Or am I missing something totally obvious?
--
Nicolas Mailhot
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
