pango multilib

[Owen Taylor]

On Tue, 2005-12-13 at 02:01 -0800, Michael A. Peters wrote:
> 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.

I don't think there really are any legitimate reasons to set *anything*
in the Pango RC file, much less set things differently for 32 and 64
bits.

> 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)

The rc file isn't just pango-querymodules (conceptually; it isn't
used for much at all right now.) So, this scheme takes the need for
separate module directories for the two copies of the library and
spreads it into other parts of Pango.

> 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.

Your scheme might be a bit better than what we have currently, but it
isn't a lot better (IMO), and I don't think it's worth a lot of pain and
churn to switch to it.

http://bugzilla.gnome.org/show_bug.cgi?id=129534 has a link to a
detailed plan a wrote up for how I wanted to do it upstreams.

> -=-
> 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.

I think trying to control module order is inherently fragile; you
are going to have some horrible %post that tries to create and/or
edit a pangorc file and that's going to be very unstable.

What I suggested to Daniel at GUADEC was to delete all the 

  { PANGO_SCRIPT_ARMENIAN, "*" },

and so forth out of basic-fc.c and leave just

  { PANGO_SCRIPT_COMMON,   "" }

That shouldn't have any affect on choice of the basic modules unless the
graphite module is installed, and then it will always prefer the
graphite module (If the graphite module lists itself as
{ PANGO_SCRIPT_COMMON,   "*" })

This doesn't encapsulate some of the tricky font-choice issues, but
ordering wouldn't help there either. There's no way by controlling
ordering that you can win over arabic-fc.c when there is a Silf table
and not when there is a GSUB table.

(Just added the same text as a comment on
http://bugzilla.gnome.org/show_bug.cgi?id=323661)

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051214/e4972eb6/attachment.sig>