Re: [gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code

[Matt Turner <mattst88@gentoo.org>]

On Mon, Nov 7, 2022 at 11:11 PM Sam James <sam@gentoo.org> wrote:
>
>
>
> > On 8 Nov 2022, at 01:10, Matt Turner <mattst88@gentoo.org> wrote:
> >
> > Noticed on ChromeOS when installing a large number of font packages in
> > parallel:
> >
> > /usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (------r--) to 2440 (r--r-S---)
> > * ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
> > *   failed to fix font files perms
> >
> > The "#new" filename is the hint. Portage uses "#new" suffixes when
> > copying files to the system, and then renames them to their final
> > filenames.
> >
> > This code was executing while another font was in the process of being
> > copied to the system. Font packages should just ensure that they install
> > files with correct permissions to begin with, and all except
> > media-fonts/x11fonts-jmk already use 0644 permissions.
> > media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
> > previous commit which changes its installed files to 0644.
> >
> > Bug: https://bugs.gentoo.org/187774
> > Signed-off-by: Matt Turner <mattst88@gentoo.org>
> > ---
> > eclass/font.eclass | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/eclass/font.eclass b/eclass/font.eclass
> > index 4970c959f7c..0196755ce3e 100644
> > --- a/eclass/font.eclass
> > +++ b/eclass/font.eclass
> > @@ -186,12 +186,6 @@ font_src_install() {
> > # @DESCRIPTION:
> > # Updates fontcache if !prefix and media-libs/fontconfig installed
> > _update_fontcache() {
> > - if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
> > - # unreadable font files = fontconfig segfaults
> > - find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
> > - -exec chmod -v 0644 2>/dev/null {} + || die "failed to fix font files perms"
> > - fi
> > -
> > if [[ -z ${ROOT} ]] ; then
> > if has_version media-libs/fontconfig ; then
> > ebegin "Updating global fontcache"
> > --
>
> Can we put an fperms call in src_install just in case (like the eclass originally had
> before moved to pkg_postinst)?

We can if you think it's necessary, but to be honest I think that the
original bug should have been WONTFIX. The user was manually
installing fonts into their system and then complained that things
didn't work when they configured the fonts with the wrong permissions.

I don't think fonts getting installed with unreadable permissions is a
real problem.