I think I've found a workable solution - at least for the time being. Unfortunately, they need to fix their code - update to rawhide g++ found some problems (which I've reported) so it doesn't build at the moment. At any rate - I would really appreciate feedback on my solution if anyone is so inclined. http://mpeters.us/silgraphite/ http://mpeters.us/silgraphite/silgraphite.spec http://mpeters.us/silgraphite/pango-silgraphite-README.fedora The solution I came up with is to install a /usr/share/pango-silgraphite directory. In that directory - a pangorc or pangorc64 file (so that both versions could be installed) in the %post scriptlet - it checks to see if an /etc/pangorc file with the correct information exists (if it does, user put it there - I don't). If correct info not there - it sets the PANGO_RC_FILE to what it installed in /usr/share/pango-silgraphite/ before running pango-querymodules thus creating an appropriate pango.modules file. This _will_ be undone by any update to pango since it will run pango-querymodules without any conf file thus using the default module path that only includes the core pango modules. For that reason - I've created a README.fedora file that tells 32-bit users how to copy the pangorc file to /etc/pango/ (which would be respected by pango-querymodules when pango is updated) 64-bit users can't do that because it would cause problems if they have both 32 and 64 bit pango. So instructions are there for 64-bit users telling them how to manually recover from a pango update wiping it. It's the best I could come up with. Proper solution would involve upstream making their pango modules less dependent upon order of pango modules in pango.modules - so that they could just be put in same directory as core pango modules. At some point hopefully that will happen. A better but not as good solution would be a fix of the core pango packages so that 32 and 64 don't both want to use the same config file it it exists. But Owen Taylor said he'd rather not go that direction at this point, but that bug http://bugzilla.gnome.org/show_bug.cgi?id=129540 being fixed is better than messing with existing pango packages. So I think what I came up with - while less ideal than above two solutions - is the best way to do it. Comments (including better way) would be appreciated. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
