pango multilib

[Michael A. Peters]

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175510
Ignore the patch I added - it's not the right thing to do.

Fedora ships two builds of pango - one for 32-bit and one for 64-bit
This makes sense because 64-bit systems are likely to want both versions
installed (assuming 32-bit install of Firefox, needed for 32-bit
plugins, will want 32-bit pango - I don't know but that makes sense)

It seems to me though that other than the pango.modules file, there is a
conflict with the configuration files.

It looks both 32 and 64 will want to use /etc/pango/pangorc (if it
exists) and both will want to use ~/.pangorc (if it exists) and both
will want to use the environmental variable PANGO_RC_FILE (if it is set)

Unfortunately, those can only be correct for one or other - not both.

My idea - for 64-bit builds, patch it to use
/etc/pango/pangorc64 ~/.pango64 and PANGO64_RC_FILE
update the pango-querymodules.1 man page for 64-bit to reflect that, and
change its name to pango-querymodules-64.1 (since pango-querymodules is
changed to pango-querymodules-64 already)

I have a patch on my system that does that, but w/o a 64-bit system I
can't test it.

-=-
Currently - Fedora uses an arch specific place for the pango.modules
file. IE - /etc/pango/i386-redhat-linux-gnu/pango.modules

I would suggest changing that back to
/etc/pango/pango.modules

and for the 64bit build - use
/etc/pango/pango64.modules

The rename of pango-querymodules to pango-querymodules-32 should be
undone imho.

-=-
The result would be - 32-bit is like upstream intends it, with where the
files are located etc.

The 64-bit would have config files at

/etc/pango/pango64.modules /etc/pango/pangorc64
~/.pangorc64 /usr/bin/pango-querymodules-64 /usr/man/man1/pango-querymodules-64.1

No file conflicts, they could be installed side by side - and the
current scenario where the same (optional) but incompatible config files
are used by 32 and 64 would be resolved.

Simplifying the pango.modules path to not have the host stuff in it
would also make it easier to script rpm scriptlets that need to run
pango-querymodules to regenerate the pango.modules file.

-=-
Thoughts on this? Are there other apps that would break by changing the
pangorc name for 64-bit? I kind of doubt it because they are optional,
and other apps should be getting that info from pango.

-=-
Where this is needed:

http://mpeters.us/silgraphite/

It's a library and a set of pango modules, and they need to be seen by
pango in a specific order (the pango base modules are suppose to be
first in the pango ModulePath)

To properly package the pango wrapper, it needs to be able to add the
path to its modules to Pango's ModulesPath - and that is broken right
now because the config files where that is set would set for both 32 and
64 bit pango.

-=-
Any other solutions would be appreciated.