Bugzilla Bug 183576

/etc/fonts/fonts.conf.new is listed in
/var/db/pkg/media-libs/fontconfig/CONTENTS but it isn't actually installed in
the system.

Reproducible: Always

It's a trick to circumvent the /etc config protection, it gets removed in
postinst. That's why it does show up in CONTENTS, but doesn't exist on the live
filesys. It's the same file as fonts.conf.

It's intended behaviour, not a bug.

If it's listed in CONTENTS it should be installed. I'd class that as a bug.
Surely there's a way that CONTENTS should not pick it up.

Yeah we could postinst change CONTENTS too in /var too ... now that would be a
clean solution (*ugh*), but for what ? Is it really that big an issue to you ?

I do not class this as a bug obviously, it's just a creative approach to a
minor shortcoming in portage.

then fix portage. I've got a build script which relies on the CONTENTS files
dictating what a package installs.

The script is barfing because this is the only package that claims to install
something and it doesn't. 

a) /var/db/pkg is not guaranteed to be any sort of stable and can and will
change frequently.  scripts and such utilizing it directly are broken.  use the
tools provided (portage-utils, gentoolkit, etc.).

b) this is a pretty ugly hack.  why can't we just add fonts.conf to
CONFIG_PROTECT_MASK?

to answer my own question: since portage only got the ability to have
individual files in CONFIG_PROTECT_MASK last Sept.

(In reply to comment #5)
> a) /var/db/pkg is not guaranteed to be any sort of stable and can and will
> change frequently.  scripts and such utilizing it directly are broken.  use the
> tools provided (portage-utils, gentoolkit, etc.).

Thanks for the reply Ryan. So what's the best tool to use to tell me what a
package has installed ?

qlist from portage-utils is very fast and gives output suitable for piping.  i
notice it too lists /etc/fonts/font.conf.new, but i don't know of any way to
override CONFIG_PROTECT for individual files other than the current hack, at
least until the required portage version is in stable for a while.

if you're doing the python thing, you might want to look at
/usr/lib/portage/bin/chkcontents for an example of how to read the CONTENTS
file through portage's API.

Right, but any approach seems to list the /etc/fonts.conf.new file when it
doesn't exist.

So what's the best approach to fixing this in fontconfig's ebuild ??

It'd be nice to fix this as per Ryan's comment #5 (b)

fontconfig-2.4.2 now installs /etc/env.d/37fontconfig which adds
/etc/fonts/fonts.conf to CONFIG_PROTECT_MASK, and no longer installs
/etc/fonts/fonts.conf.new.  I didn't bump the ebuild revision since there are
no user-visible changes (other than fonts.conf.new is no longer in CONTENTS).

Thanks Alan!