/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!
