Bug#372508: Preparing multiarch

[Goswin Brederlow]

Package: pango1.0
Severity: wishlist

Hi,

in my effort to get packages converted to multiarch I now reached
something that has been a thorn in my side for a long time: The pango
package.

The problem is that you have a architecture dependent config file
listing the available modules (/etc/pango/pango.modules). More
troublesome generating that list requires to run a binary
(/usr/bin/pango-querymodules).

With multiarch both 32bit and 64bit libpango and plugins are needed
and the list of each can differ. You also need the 32bit and 64bit
pango-querymodules binary to generate the config file. So both config
file and binary have to be renamed.

So I have a couple of question in what direction I should go before I
supply patches:


Do users ever need to call pango-querymodules?

This looks like it will only be called from the update-pango-modules
script. If that is true then pango-querymodules should be moved into
/usr/lib/pango1.0/ [becomes /usr/arch-os-gnu/lib/pango1.0] or be
moved and renamed to /usr/lib/pango1.0/pango-querymodules.arch-os-gnu.

If users are calling pango-querymodules then it should be replaced by
a wrapper that takes the arch-os-gnu tripple to query as argument and
then calls the respective pango-querymodules for that arch. Without
argument it could go through all architectures but that could result
in many failures when trying to load the wrong modules later.


What do you want to do with the config file?

- /etc/arch-os-gnu/pango/pango.modules (simplest, configure can handle that)
- /etc/pango/pango.modules.arch-os-gnu
- /etc/pango/arch-os-gnu.pango.modules


What about /etc/defoma/config/pango.conf?

Is that file architecture dependent? Doesn't look like we need this
per architecture.


What to do about update-pango-modules / update-pangox-aliases?

Those two are scripts so they don't need to be duplicated per
architecture. But they contain the path to the plugins which differs
between architectures under multiarch. They also have to call a
different pango-querymodules for each architecture.

It might be best to add a mandatory argument to the scripts for the
arch-os-gnu tripple to be used so the script can pick the right
pango-querymodules binary, library dir and config file.

Alternatively the script could also be moved to /usr/lib/pango1.0 and
then be duplicated per architecture with the library dir and config
file hardcoded into it.


What is up with the package names?

Normaly libfoo-common contains architecture independent files for a
library and libfoo-bin the support binaries.

If pango-querymodules gets moved into /usr/lib/pango1.0 it can be
merged into libpango1.0 leaving only architecture independent files in
libpango1.0-common. The call to update-pango-modules would then also
need to move to libpango1.0-0 and the dependency reversed
(libpango1.0-0 depends on libpango1.0-common). That would enable
libpango1.0-common to be architecture all as one might expect.

MfG
        Goswin


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.16-rc4-xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)